The governance problem expands from model oversight to non-human identity governance. Agents can hold credentials, call APIs, and act across systems without a human supervising each step, so access, accountability, and auditability need to be designed around machine behaviour rather than human workflow assumptions.
When AI agents become part of the programme, what is the actual shift?
The shift is not just “more AI.” It is a change in the operating model: you are no longer governing a model as a decision-support component, you are governing software entities that can hold credentials, invoke tools, and create real system effects. That means policy, ownership, approval, and traceability have to follow the agent’s actions, not only the human request that started them.
That change is why agent identity and delegated authority become first-class design concerns. If an agent can act across multiple systems, then you need to know what it is, who sponsors it, what it is allowed to do, and how those permissions are limited, renewed, and revoked over time.
Which control problems become materially harder?
Three control problems get harder at once: access control, accountability, and auditability. Access control has to handle machine behaviour that may be dynamic and context-driven. Accountability has to distinguish user intent from agent execution. Auditability has to capture the full action chain, including the agent, the tool, the credential, and the downstream system touched by the action.
This is why agent programmes fail when they are treated like chat interfaces with a few extra integrations. Once an agent can call APIs or move data between systems, the important question becomes whether each action was authorised, attributable, and bounded to a task rather than whether the model output looked reasonable.
In practice, the programme also needs lifecycle thinking. Agent registration, ownership, credential issuance, suspension, and retirement all become operational controls. If those controls are weak, agents tend to accumulate standing access, stale secrets, and unclear responsibility boundaries.
What changes in architecture and governance when agents are in scope?
Architecture changes because agents sit at the boundary between human intent and system action. A secure programme separates the human instruction layer from the execution layer, then enforces policy at the point of action. That usually means explicit delegation, scoped permissions, and logging that can reconstruct what the agent did without relying on memory or free-text prompts.
Governance changes because review can no longer stop at model approval. You need a control owner for the agent itself, plus a decision model for when the agent can act independently, when it needs human approval, and when it must be blocked from touching sensitive workflows. For enterprise programmes, AI Agent Authorisation Guide is the clearest starting point for those boundaries.
Programme design should also assume that not every agent deserves the same trust. Zero Trust for AI Agents reinforces the operational idea that each request should be evaluated at runtime, rather than inheriting broad standing privilege from the environment.
Risk and Threat Considerations
Once agents hold credentials and can act across systems, the main risk is blast radius. A single compromised prompt, poisoned tool call, or over-scoped token can turn an apparently narrow automation into broad unauthorised action. The same structure also makes abuse easier to hide, because activity may look like legitimate system traffic unless the agent’s identity and intent are logged well.
Failure mechanism: Excessive privilege, weak delegation, or poor separation between human approval and machine execution allows the agent to perform actions the operator never reviewed in detail. Attackers can exploit that gap through token theft, consent abuse, tool misuse, or manipulation of the agent’s context and inputs.
Impact: The result can be cross-system data exposure, unauthorised transactions, destructive operations, and audit trails that cannot explain who really authorised the action. At scale, one badly governed agent pattern can replicate the same risk across many workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack surface, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | AI agents authenticate with credentials and tokens that can be misused or stolen. |
| NHI-05 — Overprivileged NHI | Enterprise agents often need least-privilege design to limit damage from abuse. | |
| NHI-01 — Improper Offboarding | Agents need retirement and revocation controls when roles or projects end. | |
| Recommendation — Enforce phishing-resistant authentication and tightly scoped agent credential handling. Reduce standing access and grant only task-scoped agent permissions. Revoke dormant agent credentials and remove unused agent registrations promptly. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agents can overreach through delegated authority or mis-scoped permissions. |
| ASI02 — Tool Misuse | Agents can misuse APIs and tools when execution paths are not bounded. | |
| ASI10 — Rogue Agents | Poor governance can let agents act outside intended oversight or ownership. | |
| Recommendation — Constrain agent authority and require explicit per-action policy decisions. Restrict which tools an agent may invoke and validate each tool call. Detect and quarantine agents that operate outside approved ownership and policy. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agents and services authenticating to systems need strong machine authentication. |
| Recommendation — Use strong service authentication and rotate agent credentials regularly. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Agent execution fits continuous verification and explicit policy enforcement. |
| Recommendation — Verify each agent request continuously and do not rely on implicit network trust. | ||
| ISO/IEC 42001:2023 | 4.1 — Understanding the organization and its context | Enterprise AI programmes need governance context that includes autonomous agents. |
| 8.2 — Risk assessment of AI system impacts | Agents change risk by enabling autonomous cross-system action and delegated authority. | |
| Recommendation — Document where agents fit in the AI management system and ownership model. Assess agent autonomy, access scope, and operational impact before deployment. | ||
Practitioner Guidance
What to prioritise: Start with the highest-impact agent, not the fanciest one. The first governance pass should cover any agent that can create, delete, approve, transfer, or exfiltrate data, because those actions create the most serious blast-radius and attribution problems.
What to verify: Confirm that each production agent has a named owner, a clearly scoped task boundary, a revocation path, and an audit trail that records both the agent and the credential used. If you cannot answer those four questions cleanly, the programme is not ready for broad autonomy.
Practitioner takeaway: The key design choice is not whether agents may act, but whether every meaningful action is constrained, attributable, and reversible enough to survive real operational use.
Related resources from NHI Mgmt Group
- What are the main reasons AI agents struggle to achieve enterprise-scale deployment?
- How should security teams govern AI agents that can access enterprise systems?
- When is it crucial to implement least-privilege access for AI agents?
- What is the difference between managed identities and hardcoded secrets for AI agents?