They should inventory agents as governed identities, recertify effective access, and require change evidence for creation, approval, and deployment. The audit target is the full execution path, including delegation and ownership, not only the initial assignment of permissions. Without that, control testing will miss the most important risk.
How to treat AI agents as auditable ITGC subjects
Organisations should not audit AI agents as if they were simple software features. In ITGC testing, the agent must be treated as a governed execution subject with ownership, approval, and lifecycle evidence, because it can act, delegate, and persist access in ways that change control conclusions. The audit question is whether the organisation can explain, evidence, and challenge the agent’s full authority path.
That means the control objective is broader than “who provisioned the account” or “who approved the deployment.” An effective audit needs to show what the agent can do, who owns those powers, when they were reviewed, and whether those permissions still match the business purpose. NHIMG’s AI Agent Authorisation Guide is useful here because it frames least privilege, delegated authority, and human approval as the basis for effective access review.
For ITGC purposes, auditors should expect evidence at the identity, access, and change layers together. If the agent can invoke tools, call APIs, or act under delegated authority, those effective rights belong in the audit scope even when the initial assignment looked narrow. Agentic AI Identity Guide and Zero Trust for AI Agents both support the same practical conclusion: standing trust is the problem, not just the provisioning event.
What the audit evidence should prove
The strongest test is whether the organisation can reconstruct the agent’s control story from creation through current operation. That story should include the inventory record, owner, business purpose, approved scope, delegated credentials or tokens, deployment target, and any subsequent change requests or recertifications. If any of those links are missing, the control design is weak even if a ticket exists.
Audit evidence should also show that access review covered actual runtime capability, not only a configuration label. A task-scoped agent with broad underlying access is still overexposed if it can execute outside the intended business process. NHIMG’s AI Agent Observability, Audit and Incident Response Guide reinforces that effective attribution and action logging are what make post-deployment review credible.
Where agents are part of a development or operations chain, the audit should verify that changes to prompts, tools, connectors, policies, and deployment configuration were themselves controlled changes. That is especially important when the agent can influence production systems, because the absence of a formal change trail usually means the control is incomplete rather than merely undocumented.
Why full execution-path review matters for ITGCs
ITGCs fail when the organisation audits the front door but ignores the path the agent uses after it starts operating. The execution path can include delegated authority, inherited credentials, hidden tool access, approved exceptions, and ownership drift. Those are the places where control objectives break down, because the agent’s real power often exceeds the original approval record.
That is also why recertification must test effective access, not just named entitlements. If the agent’s permissions were approved months ago, but the model, connector set, or runtime policy has changed since then, the old approval no longer proves the current control state. In practice, this is where many reviews become paper exercises rather than evidence of operating effectiveness.
When agents sit inside finance, controls, or other SOX-adjacent processes, auditors should be especially alert to delegated actions that can trigger downstream system changes without a second human review. The relevant question is not whether a human approved the agent once, but whether the current operating model still constrains the agent’s authority to the approved business process.
Risk and Threat Considerations
AI agents create a control gap when organisations assume the original permission grant is the whole story. The agent may later gain broader effective access through delegation, tool reuse, shared credentials, or deployment drift, and that can let a compromised or misused agent bypass the very controls the audit is meant to test.
Failure mechanism: The organisation tests creation approval but not runtime authority, so excessive access, stale ownership, or unreviewed tool connections remain invisible until a change, abuse, or incident exposes them.
Impact: The ITGC conclusion becomes unreliable, because the organisation cannot demonstrate that the agent’s actual execution path stayed within approved scope or that high-risk access was periodically recertified.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents in ITGCs can exceed approved authority through delegation and overbroad access. |
| Recommendation — Test effective agent authority and constrain delegated privilege to the approved execution path. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | The question is about auditable evidence for agent actions and control testing. |
| AC-6 — Least Privilege | ITGC audit should confirm the agent's effective access stays limited to its business purpose. | |
| CM-3 — Configuration Change Control | Agent creation, approval, deployment, and tool changes are change-controlled events. | |
| Recommendation — Review agent audit records to reconstruct creation, delegation, and production-impacting actions. Limit each agent to the minimum access needed for its approved function. Require approved change evidence for agent deployment and material runtime changes. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged access rights | Agents with delegated or production-impacting authority need privileged access governance. |
| Recommendation — Review and restrict privileged access granted to agents and their execution paths. | ||
Practitioner Guidance
What to verify: Require an inventory that ties each agent to an owner, approved business use, effective privileges, delegated access paths, and the evidence used for the latest recertification. If the organisation cannot show all five, treat the control as incomplete rather than partially effective.
Decision rule: If the agent can perform production-impacting actions, audit the runtime permissions and delegated execution path as part of the ITGC test, not as a separate technical review. If the control only proves the initial grant, it is not enough for operating-effectiveness testing.
Practitioner takeaway: The right audit unit is the agent’s full authority lifecycle, not the permission ticket that launched it; if you cannot evidence creation, ownership, delegation, and current effective access together, you have not really tested the control.