By NHI Mgmt Group Editorial TeamPublished 2026-06-23Domain: Agentic AI & NHIsSource: Incode

TL;DR: AI agents are moving from assistive tools to systems that open accounts, request access, move money, and act continuously, while MCP standardises connectivity without solving identity or accountability, according to Incode. The real issue is not agent capability, but the collapse of assumptions that identity is human-paced, request-bound, and reviewable after the fact.


At a glance

What this is: Incode argues that AI agents are becoming active digital actors, but current infrastructure still lacks standard ways to verify who an agent represents or trace its actions back to accountability.

Why it matters: IAM, IGA, PAM, and NHI programmes need to treat agent identity as a governance problem now, because autonomous actions create access, approval, and audit gaps that human-centric controls do not close.

By the numbers:

👉 Read Incode's analysis of the identity problem created by AI agents


Context

AI agent identity is the point where automation turns into governance. The article’s core claim is that agents are moving from passive assistants to systems that initiate actions, make decisions, and persist across workflows without a human approving each step.

That shift matters because current identity models assume a request can be tied to a known actor, reviewed in a stable access window, and traced after the fact. Once an agent can act continuously on behalf of a person or organisation, IAM, NHI, and accountability controls all need to cope with software entities that are not human, but are not simply static machine accounts either.


Key questions

Q: How should organisations govern AI agents that act on behalf of users?

A: They should bind each agent to a verified principal, define explicit scope, and monitor actions continuously. The key is to treat the agent as a governed identity, not just a workflow tool. If the organisation cannot say who the agent represents and what it may do, the access model is too weak for production use.

Q: Why do AI agents create new identity risk compared with normal automation?

A: Because they can make runtime decisions, choose actions dynamically, and continue operating without a human approving each step. That means the system is not just executing a script. It is acting within a delegated trust relationship that can expand or drift during the session, which conventional automation controls do not fully address.

Q: What breaks when an agent can act without a clear accountable owner?

A: Auditability, incident response, and governance all degrade at the same time. If the organisation cannot tie actions back to a verified human or business entity, it may log the event but still be unable to assign responsibility, assess scope, or revoke the right authority quickly enough.

Q: How can security teams evaluate whether their agent controls are sufficient?

A: They should test whether each control still works when the agent acts continuously, changes tools mid-session, or completes multiple actions without fresh approval. If the answer depends on a human noticing the problem later, the control is not sufficient for autonomous behaviour.


Technical breakdown

Why MCP connectivity does not solve agent identity

Model Context Protocol standardises how AI agents connect to tools, APIs, and data sources, but interoperability is not identity. A protocol can move requests between systems without proving who the agent represents, what authority it has, or whether the action is attributable after execution. That is the gap the article highlights: transport and tool access are becoming easier, while authorisation and accountability remain fragmented. In practice, an agent can appear legitimate inside a workflow even when the trust chain behind it is weak or missing.

Practical implication: treat MCP connectivity as an integration layer, not an identity control, and require separate verification and audit binding for every agent.

Agent-principal binding is the missing control plane

The article’s strongest architectural point is that an agent must be bound to a verified owner or organisation before its actions can be trusted. In identity terms, this is a principal relationship, not a simple session token. Without that binding, the system can record what happened but cannot say who is accountable for it in a way that supports governance, reversal, or incident response. This is especially important when agents can open accounts, move money, or interact with external parties at machine speed.

Practical implication: establish explicit principal binding for agents so every action can be tied to an accountable owner and reviewed in context.

Autonomous agent behaviour creates a different governance problem than NHI

These systems should still be treated as non-human identities, but they are not ordinary service accounts. The difference is runtime decision-making: the agent can choose actions, sequence tasks, and continue operating without a human gate between each step. That changes how least privilege, monitoring, and approval boundaries work. Instead of provisioning a fixed identity for a fixed workload, practitioners now have to govern an identity that can adapt its own execution path within the scope it has been given.

Practical implication: design controls for runtime behaviour, not just static entitlements, because the agent can change what it does without changing who it is.


NHI Mgmt Group analysis

AI agent identity collapses the assumption that access can be understood at provisioning time. Traditional IAM and NHI governance assume intent is knowable when access is issued. That assumption fails when an agent can decide, at runtime, which systems to touch, which actions to chain, and when to continue without a human approval gate. The implication is that identity governance must stop treating access as a fixed property of issuance and start treating it as a moving runtime state.

MCP expands connectivity faster than accountability expands governance. The protocol solves tool interoperability, not trust. That means enterprises can connect agents to more data and more systems before they have a reliable way to verify principal, scope, or action lineage. For identity teams, the danger is not simply overreach but unowned reach, where an approved connection creates execution paths no one can clearly attribute.

Agent-principal binding: the control gap here is not lack of access, but lack of a durable link between the agent and the accountable human or organisation. Once that link is missing, auditability becomes retrospective guesswork. NHI programmes should recognise that an agent acting on behalf of someone is not the same as a service account executing a predefined job. The practical conclusion is that accountability has to be designed as part of identity, not bolted on after deployment.

Autonomous agents force a re-think of privileged access boundaries. PAM assumptions built around human request flows and bounded admin tasks do not map cleanly to agents that can act continuously and interact with third parties. This does not just add a new class of credential risk. It changes the shape of privilege itself, because the actor can self-select actions across time. Practitioners should expect access governance to move toward dynamic, behaviour-aware controls.

Agentic identity will expose the weakest link between human IAM and NHI governance. The article shows why these domains can no longer be managed separately when a software entity acts on behalf of a person, but executes like a machine. That creates a bridge problem for identity architecture, where ownership, consent, delegation, and runtime authority all have to line up. Teams that keep human IAM and NHI controls in separate operating models will miss that overlap.

From our research:

  • 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
  • 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, according to SailPoint.
  • The same report shows that 98% of companies plan to deploy even more AI agents within the next 12 months, which means governance pressure is rising faster than control maturity.

What this signals

Agent-principal binding is becoming the practical line between delegated automation and unmanaged autonomy. As agent deployments spread, identity teams will need governance that can tie each runtime decision to an accountable owner and a defined scope, rather than relying on post hoc investigation.

The pressure point is not just AI adoption, but the overlap between human IAM, PAM, and NHI governance. Organisations that keep those operating models separate will struggle to explain who authorised an agent, who owns its access, and who can revoke it when behaviour drifts.

With 92% of organisations saying governing AI agents is critical but only 44% already having policies in place, the gap is no longer conceptual. Security teams should expect agent identity to move from innovation discussion to access review, audit, and incident-response planning quickly.


For practitioners

  • Map every agent to a verified principal. Document who each agent represents, what it may do, and which business owner is accountable for its actions before it is allowed to touch production systems.
  • Separate connectivity from authorisation. Treat MCP and similar integration paths as transport only, then enforce independent verification, scope checks, and logging before any sensitive action is executed.
  • Redesign approval gates for runtime behaviour. Replace assumptions built around human-paced requests with controls that can inspect agent actions continuously and stop scope drift before the next tool call.
  • Align PAM and NHI controls to agent execution paths. Review whether privileged workflows still depend on a person in the loop, then map where an agent can chain actions beyond the original request boundary.

Key takeaways

  • AI agents are no longer just automation tools, they are emerging identity subjects that can change the governance model itself.
  • The hardest problem is accountability, because current infrastructure can connect agents to tools without proving who they represent or what they are authorised to do.
  • Practitioners need runtime identity controls, principal binding, and behaviour-aware governance before agent deployments scale 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 AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10The article focuses on AI agent identity, accountability, and tool-use risk.
OWASP Non-Human Identity Top 10NHI-01Agent identities are non-human identities that need governance and traceability.
NIST AI RMFGOVERNThe article centres on accountability, ownership, and oversight for AI agents.
NIST CSF 2.0PR.AC-4Agent scope and access boundaries align with least-privilege access governance.
NIST Zero Trust (SP 800-207)Continuous verification fits the article's concern about runtime trust decisions.

Map agent identity and tool-use controls to agentic security requirements before production deployment.


Key terms

  • Agent-principal binding: The link between an AI agent and the verified person or organisation it represents. In practice, this is what makes the agent's actions attributable and governable. Without it, the agent may be able to act, but the enterprise cannot reliably assign responsibility or enforce accountability.
  • Agentic identity: An identity model for software entities that can choose actions, sequence work, and continue execution without a human approving every step. Unlike a static service account, an agentic identity needs runtime governance because its behaviour can change while its credentials and permissions remain the same.
  • Runtime authorisation: An access decision made while the system is operating, based on current context and behaviour rather than only on the permissions granted at provisioning time. For AI agents, runtime authorisation matters because the correct decision may change as the agent's task, tool use, or scope evolves.
  • MCP: Model Context Protocol, Anthropic's open protocol for connecting AI agents to tools and data sources. It standardises integration, but it does not by itself prove identity, assign accountability, or define the authorisation logic needed for secure agent governance.

What's in the full article

Incode's full post covers the operational detail this analysis intentionally leaves for the source:

  • How the vendor describes its Trust Graph approach for detecting and classifying agent activity across human and machine surfaces.
  • The four-step agentic identity workflow, including owner binding, token issuance, and ongoing anomaly monitoring.
  • The article's explanation of how the model avoids exposing personally identifiable information while preserving auditability.
  • Ricardo Amper's full remarks on why agent identity is a policy, product, and societal issue.

👉 Incode's full post covers the agentic identity model, the accountability gap, and the control flow behind its approach

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-23.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org