TL;DR: Agentic systems are turning every AI agent into a distinct identity that can query data, call APIs, and orchestrate workflows, while most enterprises still govern them like application extensions, according to AppSOC. That mismatch leaves actions without accountability and makes identity the real control plane, not MCP integration details.
At a glance
What this is: This is an analysis of why AI agent security is fundamentally an identity problem, with MCP serving as the trigger that exposed weak governance for agent identities.
Why it matters: It matters because IAM, PAM, and IGA programmes now have to govern autonomous machine action, not just human access and static service accounts.
👉 Read AppSOC's analysis of the agentic identity crisis in AI security
Context
MCP and similar agent connectivity layers have made it easier for AI systems to reach databases, SaaS platforms, and cloud tools, but connectivity is not the same as governance. The primary gap is identity: when agents can decide, act, and persist across systems, access controls designed for users and service accounts stop describing what is actually happening.
This is the point where identity-first security becomes a practical requirement for AI agent identity, not a theoretical preference. The article argues that organisations are already accumulating non-human identities without clear ownership, lifecycle control, or action-level accountability, and that is the real exposure rather than the protocol itself.
Key questions
Q: How should organizations manage the identity risks associated with AI agents?
A: Organizations should enhance visibility into AI agents by incorporating robust monitoring and evaluation processes within their IAM frameworks. Regularly reviewing access rights and implementing stringent access controls will help mitigate risks and ensure IAM strategies align with evolving technologies.
Q: Why do AI agents break traditional IAM assumptions?
A: AI agents break IAM assumptions because they do not behave like predictable users. They can authenticate to multiple systems, select tools dynamically, and execute tasks at machine speed without a human approval gate between actions. That removes the stable login session that traditional IAM uses as its trust anchor.
Q: What breaks when AI agents are managed like ordinary machine identities?
A: What breaks is the assumption that access scope can be fully understood from provisioning data and quarterly review. Ordinary machine identities are repeatable; agents are not. If teams only review entitlements, they miss context shifts, delegated actions, and credential creation inside the session.
Q: Who should own AI agent identity governance in an enterprise?
A: AI agent identity governance should sit jointly with IAM, platform security, and application owners because the risk crosses the runtime, the proxy, and the receiving service. No single team can see the whole delegation chain unless identity context is preserved end to end.
Technical breakdown
Why MCP turns AI agents into identity subjects
Model Context Protocol connects agents to tools and data sources, but the security consequence is that each agent becomes an identity that can be authenticated, authorised, observed, and revoked. In agentic systems, the useful unit of control is no longer the application or the network path. It is the actor that initiates actions, selects tools, and may do so repeatedly across sessions. That is why treating MCP as a transport problem misses the security boundary. The boundary is identity, because identity determines intent, scope, and accountability.
Practical implication: inventory AI agents as governed identities, not application features.
Why traditional IAM assumptions fail for agents
Traditional IAM assumes behaviour is relatively predictable, ownership is clear, and access can be reviewed against a stable role or business function. Agentic systems violate all three assumptions because they can generate large volumes of actions, adapt to context, and operate without a single human behind every decision. That makes static provisioning logic and point-in-time authentication insufficient for the way agents actually use access. The problem is not just excess privilege. It is that the governance model no longer matches the runtime behaviour.
Practical implication: move from one-time access assignment to continuous identity governance for agent behaviour.
Why tool-level authorisation matters more than connectivity
An agent can be authenticated and still be unsafe if it is allowed to call the wrong tool, combine data in the wrong context, or trigger downstream workflow steps that were never intended for that identity. Tool-level authorisation narrows the decision from can the agent connect to can this specific agent perform this specific action right now. That is a much more precise control point for agentic environments because it aligns access with action intent. Without it, authentication only proves the agent exists, not that it should be trusted to act.
Practical implication: authorise agent actions at the tool and operation level, not just at login.
NHI Mgmt Group analysis
Every AI agent is a non-human identity, and treating it as anything else creates governance blind spots. The article is right to frame MCP as an identity problem because the security consequence is not connectivity alone, it is the creation of machine identities that can act across systems. Once agents can query, modify, and orchestrate workflows, they belong in the same governance model that already covers service accounts, tokens, and certificates. The practitioner conclusion is simple: if the identity is not governed, the agent is not governed.
Traditional IAM assumptions collapse when the actor can change behaviour at runtime. Predictable behaviour, stable ownership, and reviewable access were designed for humans and conventional service accounts. Agentic systems can produce thousands of actions per hour, adapt to context, and keep operating without a clearly accountable human owner. The implication is not just that controls need tuning. The underlying assumption that access can be fully described at provisioning time no longer holds.
Identity is the control plane for agentic security, not an extra layer on top. Prompt filters, network boundaries, and output validation can reduce noise, but they do not answer the core question of who or what is acting. When identity is not the primary boundary, organisations cannot trace actions, constrain scope, or prove policy alignment with confidence. The practitioner conclusion is that agent governance has to start at identity design, not after deployment.
Continuous discovery is now a governance requirement, not an operational convenience. The article’s point about new agents, tools, and integrations constantly appearing is the same challenge NHIs have created elsewhere in the enterprise: assets proliferate faster than manual control planes can absorb them. That makes discovery, inventory, and ownership mapping essential to avoid shadow AI and unmanaged agent identities. The practitioner conclusion is to govern agent sprawl as an identity lifecycle problem.
Tool-level authorisation is the right response to intent ambiguity. Agents may be authenticated and still act outside the business purpose that justified their access. Fine-grained authorisation at the tool and action layer is what keeps the governance model close to runtime behaviour. The practitioner conclusion is to stop measuring only whether an agent can connect and start measuring whether it should be allowed to execute this action in this context.
From our research:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Our research also found that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
- For a broader control model, see OWASP Agentic AI Top 10 for the runtime risks that identity controls must contain.
What this signals
Agent governance is becoming a lifecycle problem before it becomes a tooling problem. When autonomous systems proliferate faster than ownership and review processes can keep up, the gap shows up first in identity records, not in dashboards. Organisations that already struggle with service account sprawl should assume the same pattern will repeat with agents unless lifecycle governance is redesigned for machine pace.
Shadow AI will behave like shadow IT unless discovery is tied to access control. Continuous discovery only matters if the identities it finds are actually mapped to permissions, audit trails, and revocation paths. The practical shift is to treat every new agent as both a security asset and a governance obligation, then verify that it is visible in IAM, PAM, and monitoring workflows.
The strongest near-term signal is not how many agents are deployed, but how many can be explained. If an organisation cannot answer who owns the agent, what it can do, and when its access will be removed, the programme is already behind the operating reality.
For practitioners
- Inventory agents as first-class identities Map every deployed agent, connector, and runtime token to an accountable owner, business purpose, and review cycle. Include shadow AI discovery so unmanaged agents do not sit outside IAM and PAM oversight.
- Separate authentication from action authorisation Require per-tool and per-operation authorisation for agent actions, especially where agents can read data, modify records, or trigger workflows across multiple systems.
- Apply lifecycle governance to agent credentials Track provisioning, rotation, revocation, and offboarding for agent tokens and OBO relationships the same way you would manage other non-human identities.
- Build audit trails that preserve agent context Log which agent acted, which tool was invoked, what data was accessed, and whether the action was on behalf of a human or another system.
- Test controls against autonomous runtime behaviour Review whether current IAM and IGA processes still work when an identity can change behaviour mid-session and generate high volumes of actions without human approval.
Key takeaways
- AI agent security is an identity problem because agents act as non-human identities, not as ordinary software features.
- The governance failure is not connectivity alone, but the loss of accountability, lifecycle control, and action-level authorisation.
- Practitioners should move agent governance into IAM, PAM, and lifecycle processes before deployment scales further.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic tool misuse and identity abuse are central to the article. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | The article treats agents as first-class non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and entitlement management are directly implicated. |
| NIST Zero Trust (SP 800-207) | Continuous verification fits identity-first agent governance. | |
| NIST AI RMF | GOVERN | AI governance and accountability are core to the article's thesis. |
Map agent actions to OWASP agentic risks and enforce action-level controls before deployment.
Key terms
- Agentic AI Identity: The complete set of credentials, permissions, and governance controls applied to an autonomous AI agent — covering authentication, authorisation, action logging, and access revocation. Distinct from traditional NHI because agent identities are often ephemeral, delegated, and multi-hop.
- Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
- Identity-first security: Identity-first security is an approach that treats identity as the primary control plane for managing risk. Instead of relying mainly on network or endpoint boundaries, it uses identity context to decide what can happen, when it can happen, and under what conditions. That model is especially relevant where privileges move across human, non-human, and agentic actors.
- Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
What's in the full article
AppSOC's full article covers the operational detail this post intentionally leaves for the source:
- How the PointGuard MCP Security Gateway applies strong agent authentication and OBO tokenisation in practice
- How runtime guardrails and DLP are combined with identity context for agent actions
- How continuous discovery is used to inventory AI assets and reduce shadow AI exposure
- How tool-level authorisation changes the control model for agentic environments
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity controls across human and non-human systems, it is worth exploring.
Published by the NHIMG editorial team on August 15, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org