Accountability should stay with the human or team that approved the manifest and owns the workflow. The verifier can issue a narrow, state-bound capability only after trusted evidence satisfies the policy, but it should not replace ownership. Humans remain responsible for judgments that cannot yet be reduced to executable rules, including whether the resulting action is appropriate.
Why Accountability Cannot Shift When an AI Agent Gains New Access
When an AI agent earns a new permission, the operational question is not just whether the policy engine allowed it. The real issue is who remains responsible for the decision, the workflow outcome, and the risks that follow. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 is consistent on one point: autonomy does not remove human accountability. The organisation that approved the manifest, defined the workflow, and accepted the business risk still owns the outcome, even if a verifier grants a narrow capability at runtime.
This distinction matters because AI agents can chain tools, change tactics, and act beyond the original expectation of the requester. NHIMG has documented how agentic systems can overreach in practice, as seen in Replit AI Tool Database Deletion and CoPhish OAuth Token Theft via Copilot Studio. In practice, many security teams encounter accountability gaps only after an agent has already crossed a scope boundary, rather than through intentional governance design.
How Runtime Permissioning Should Work Without Losing Ownership
Best practice is evolving toward a split between decision authority and operational execution. The human owner or accountable team approves the manifest, defines the permitted goal, and sets policy constraints. A verifier or policy engine then evaluates each request in context and can issue a state-bound, time-limited capability only when the evidence matches the policy. That keeps the agent on a short leash without pretending the verifier is the owner.
In agentic environments, static role-based access control is usually too blunt. Agents do not follow fixed human schedules or predictable task paths, so RBAC alone cannot express “this model may read billing data only when reconciling a ticket and only for the current task.” Current guidance suggests using intent-aware, context-aware authorisation with policy-as-code, evaluated at request time. The practical goal is to bind permission to the task, not to the actor’s general status.
- Use workload identity to prove what the agent is, not just what secret it holds.
- Issue just-in-time credentials with short TTLs and automatic revocation when the task ends.
- Require policy checks on every sensitive action, not only at login or deployment.
- Log the manifest owner, approver, verifier decision, and downstream action in one audit trail.
That model aligns with the control thinking in OWASP Non-Human Identity Top 10 and the implementation direction in CSA MAESTRO agentic AI threat modeling framework. It also fits the failure patterns exposed in Amazon Q AI Coding Agent Compromised, where the dangerous issue was not merely access, but the agent’s ability to execute a harmful action once access existed. These controls tend to break down when teams rely on long-lived service accounts for high-autonomy agents because the credential outlives the context that made it safe.
Where Accountability Models Break Down in Real Deployments
Tighter runtime control often increases engineering and governance overhead, requiring organisations to balance safety against latency, operational friction, and the need for rapid automation. There is no universal standard for this yet, especially for multi-agent systems where one agent’s permission can become another agent’s trigger.
One common edge case is delegated escalation. If an agent can request new permission from another workflow, accountability still sits with the human owner of the parent process, not with the temporary verifier that granted the token. Another is cross-system chaining, where an apparently narrow capability becomes risky once the agent combines tools. This is why the question should not be “who got the token,” but “who authorised the agent to pursue this goal under these constraints?”
NHIMG’s AI Agents: The New Attack Surface report shows how often agent behaviour escapes intended scope, which is why accountability must remain attached to the workflow owner and not be delegated to the control plane. The same logic underpins the NIST AI Risk Management Framework: governance, mapping, and oversight remain necessary even when technical controls are automated. In highly regulated environments, this approach becomes harder when legal, security, and product teams all share control without a single named accountable owner.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Covers agent autonomy and unsafe tool use that can outgrow approved scope. |
| CSA MAESTRO | GOV-1 | Addresses governance and ownership for agentic workflows and delegated actions. |
| NIST AI RMF | The AI RMF governance function supports clear accountability for AI decisions. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Non-human identities need scoped, auditable permissions even for autonomous agents. |
| NIST Zero Trust (SP 800-207) | Enforce explicit verification | Zero Trust requires continuous verification before each sensitive action or permission gain. |
Assign one accountable owner per agent workflow and require approval for any permission change.
