Treat AI agents as separate identity subjects with their own approvals, scope limits, and monitoring. Human access policy assumes a person controls the session, but agentic access can chain actions across tools and timing. Governance should separate authentication from authorisation and require explicit policy for non-human actors before they are allowed to reach business apps.
Why This Matters for Security Teams
When AI agents and humans share the same business apps, the core risk is not just shared login surfaces. It is shared execution authority. A human session is usually bounded by a person’s attention and intent; an agent can chain API calls, move across tools, and act faster than manual review can contain. That makes simple user-centric IAM too coarse for governance. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward runtime controls, not just static entitlements.
NHI Management Group’s research shows why this matters operationally. In The State of Non-Human Identity Security, only 1.5 out of 10 organisations said they were highly confident in securing NHIs, which is a signal that identity governance for machine actors is still immature. In practice, many security teams encounter AI-driven access failures only after data exposure, over-sharing, or tool abuse has already occurred, rather than through intentional design.
How It Works in Practice
The practical answer is to treat agents as separate identity subjects, then govern their app access by task, context, and runtime policy. Human approvals can still matter, but they should not be the only control plane. An agent should have its own identity, its own scope, and its own monitoring trail. That usually means workload identity for proof of what the agent is, plus short-lived credentials for what it may do right now. In agentic environments, static role assignments often fail because the access pattern is not stable enough to predefine cleanly.
Security teams are increasingly using patterns aligned to SPIFFE-style workload identity, OIDC tokens, and policy-as-code so authorisation can be evaluated at the moment of request. This is where intent-based or context-aware authorisation becomes useful: the policy checks what the agent is trying to do, what data it is touching, what tool it is invoking, and whether the request matches the approved objective. That approach is more consistent with the control themes in OWASP NHI Top 10 and CSA MAESTRO agentic AI threat modeling framework.
- Issue credentials per task, not per quarter, and revoke them automatically when the task ends.
- Separate authentication from authorisation so identity proof does not imply broad app access.
- Log each tool call, data lookup, and downstream action as a distinct event.
- Require explicit approval paths for high-impact actions such as exports, payments, and privilege changes.
The same model should also cover monitoring and incident response. If an agent starts chaining actions across shared apps, the security team needs a trail that distinguishes the human operator from the autonomous actor. These controls tend to break down in legacy SaaS environments where coarse app roles, long-lived API keys, and limited audit detail make per-request policy enforcement impossible.
Common Variations and Edge Cases
Tighter agent governance often increases workflow friction, so organisations have to balance autonomy against control depth. That tradeoff is real, especially when business teams want agents to act quickly inside existing SaaS tools. Best practice is evolving here, and there is no universal standard for every application stack yet.
One common edge case is a human supervising an agent inside the same session. In that model, the human may initiate the action, but the agent may execute steps the human did not explicitly review. Another is shared service tooling, where an app cannot cleanly separate user and agent permissions. In both cases, the safest pattern is to force a distinct machine identity and narrow the allowed actions to a minimal, time-bound scope. The NIST Cybersecurity Framework 2.0 and AI Agents: The New Attack Surface report both reinforce that visibility and governance must keep pace with expanding agent deployment.
Teams should be especially cautious where agents can access sensitive records, trigger workflows, or interact with third-party integrations. Those environments often expose the gap between policy intent and actual runtime behavior, and that gap widens when agents are allowed to improvise across multiple tools without fresh authorisation at each step.
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 | A2 | Addresses agent mis-scoping and unsafe tool use in shared-app access. |
| CSA MAESTRO | TR-2 | Covers threat modeling for autonomous agent actions across apps and tools. |
| NIST AI RMF | Supports governance, accountability, and monitoring for autonomous AI behaviour. |
Define per-task agent scopes and enforce runtime checks before every privileged tool action.
Related resources from NHI Mgmt Group
- How should security teams govern AI agents that use OAuth access?
- How should security teams govern AI agents that can access enterprise systems?
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams delegate access to AI agents without sharing passwords?
