Are IT administrators accountable for an AI agent’s mistakes?

Yes, for two things: the access changes they approve when an AI agent prepares them, and the connections and permissions they grant to the agent itself. IT administrators are not accountable for business decisions the agent takes inside those permissions. The record shows which permission allowed an action and who granted it.

What makes the IT administrator's position unusual?

Most reviewers approve the agent's outputs. IT administrators also shape its reach. When an admin connects an agent to the file store, the ticketing system or the identity directory, they decide what the agent can touch. A connection scoped too widely gives the agent more reach than its role needs, which is what the OWASP Top 10 for LLM Applications calls excessive agency.

That reach sits inside the minimum chain as part of the agent's role scope and sources. Whatever the agent's certificate says, it cannot act on a system it is not connected to. So the IT administrator who wires the connection sets one of the bounds every action meets.

What may an IT agent do, and what stays with the administrator?

The bottom row matters. An agent should never be able to widen its own permissions. That change belongs to a person, filed in the record like any other.

What does the record show about who decided?

Each access change the agent prepares is filed with its sources. A starter record from the HR system is sealed. A manager's ticket asking for access is declared. An email from an unknown address asking for a reset is external and should never authorise one. The record names the administrator who approved, the scope granted, and the time.

The record of connections is just as important. It shows when each connection to the agent was created, with what scope, and by whom. If an agent read a folder it should not have seen, the record shows the connection that allowed it.

An example: the contractor who got too much

Take a mid-sized engineering firm. A project manager raises a ticket asking for a new contractor to get access to "the project folders". The agent drafts an access change granting the contractor the project group, which also includes the finance share for project budgets. It notes that the group includes a sensitive share and holds the request.

The administrator approves without reading the note. The contractor can now see salary costs on every project. The record shows the declared request, the note and the approval. The administrator owns the access grant. The longer-term fix is a narrower group, which is also an IT decision.

What controls fit an IT team?

1. Agents never change their own connections. Every connection change is held for a named administrator.
2. Sensitive access needs two approvals, one from IT and one from the data owner.
3. Practise before approving alone, through a two-week practicum for IT administrators recorded in a practicum log template for IT administrators.
4. Review connections at each renewal. Agent certificates lapse after 90 days, a good moment to check scopes; see how to prepare IT administrators for 90-day recertification.

Back-office roles approving people-related changes face the same question; see payroll administrators and AI agent mistakes. The wider topic is in AI literacy and certification for people who work with agents.

Where the Academy fits

IT administrators who wire an agent's connections and scopes are close to building work, so Pryme Intelligence Academy's Builder track is often the better fit than Operator alone. Builder ends in a proctored exam and a capstone agent certified in Attest to depth 2 or higher, so the learner has scoped and certified a real agent end to end.