Three foundational concepts: Authentication (every agent has a verifiable identity distinct from other agents and from human users using dynamic ephemeral credentials), Authorisation (least privilege enforced at the agent level with JIT elevation using MCP’s Step-Up Authorisation), and Accountability (complete tamper-resistant audit trails of all agent actions linked to the specific agent identity). Organisations that implement these are positioned to deploy Agentic AI with appropriate security controls.
Why This Matters for Security Teams
Agentic AI changes the identity problem because the workload is no longer a passive service account or a human in a browser. An AI agent can plan, choose tools, chain actions, and request more access in response to its own goals. Static RBAC assumptions break when the thing making the request is autonomous. Current guidance suggests identity governance must anchor the agent to a verifiable workload identity, then evaluate authorisation at runtime against intent, context, and risk.
This is why NHI governance and agentic ai governance are converging. The same control gaps that drive secrets exposure in traditional environments also amplify agent risk: long-lived credentials, weak offboarding, and limited visibility. NHI discipline still matters, but it is not enough on its own. Organisations need the combination of identity proof, JIT credentialing, and tamper-resistant accountability that aligns with agent behaviour rather than human job functions. The Ultimate Guide to NHIs and the OWASP Agentic AI Top 10 both reinforce this shift.
In practice, many security teams encounter agent overreach only after an autonomous workflow has already chained tools and moved beyond the original approval boundary.
How It Works in Practice
A practical agentic identity governance framework starts with workload identity, not a shared token pool. Each agent should present cryptographic proof of what it is, ideally through a workload identity pattern such as SPIFFE or an equivalent OIDC-backed identity. That identity is then bound to a policy engine that evaluates what the agent is trying to do, what data it is touching, and whether the action is in scope for the current task. This is where intent-based authorisation matters more than pre-written roles. For runtime policy design, security teams can align with the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026.
Operationally, the control stack usually looks like this:
- Issue JIT credentials per task, with short TTLs and automatic revocation when the workflow ends.
- Keep secrets ephemeral and scoped to the minimum tool, dataset, or API call required.
- Log every tool invocation, policy decision, and escalation with the agent identity attached.
- Use policy-as-code so decisions are evaluated at request time, not pre-approved for broad role buckets.
- Separate agent identity from application identity so audit trails show the exact autonomous workload that acted.
That approach is consistent with the control themes in the OWASP NHI Top 10 and the accountability emphasis in 52 NHI Breaches Analysis. For threat-aware monitoring, organisations can also map adversarial behaviours to the MITRE ATLAS adversarial AI threat matrix.
These controls tend to break down when agents are allowed to reuse long-lived API keys across heterogeneous tools because one compromised token can outlive the task boundary and inherit privileges the policy engine never intended.
Common Variations and Edge Cases
Tighter agent identity controls often increase orchestration overhead, so organisations have to balance security precision against developer friction and workflow latency. There is no universal standard for every environment yet, especially where multiple agents collaborate or where an agent must operate across SaaS, cloud, and internal systems in one workflow.
One common edge case is delegated execution. If an agent hands work to another agent, the framework needs to preserve provenance so downstream actions remain attributable to the originating identity and policy context. Another is break-glass access: current guidance suggests treating emergency elevation as a separately governed path, not as a standing exception that agents can rediscover later. A third is shared infrastructure. If several agents run on the same platform, teams should isolate credentials, audit logs, and policy decisions per agent instance rather than per cluster or tenant.
For broader governance context, the Top 10 NHI Issues and NIST Cybersecurity Framework 2.0 are useful reference points, while the emerging agentic control conversation is also reflected in the NIST AI Risk Management Framework.
The practical rule is simple: where the agent can decide, the identity system must assume non-linear behaviour and prevent access from becoming a permanent capability.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AG-05 | Agentic apps need runtime controls for tool use, escalation, and identity-bound actions. |
| CSA MAESTRO | MA-02 | MAESTRO addresses orchestration, trust boundaries, and governance for autonomous agents. |
| NIST AI RMF | GOVERN | AI RMF GOVERN supports accountability and oversight for autonomous AI behaviour. |
Bind each agent action to policy checks, short-lived access, and full auditability before execution.
