Agentic AI protocols change how identity and access are governed

At a glance

What this is: Black Kite frames agentic AI as goal-driven systems that act through protocols like MCP and A2A, with identity and access becoming central governance concerns.

Why it matters: IAM, PAM, and NHI teams need to treat agentic systems as actors with delegated authority, not just applications that consume prompts.

Context

Agentic AI is not just another way to call an LLM. It is a control problem: a system that can decide, sequence, and execute actions against tools and data sources without a human approving each step. That changes the security conversation from output quality to who or what is authorised to act, under which constraints, and for how long.

The article sits squarely in the gap between AI orchestration and identity governance. Once an agent can plan across multiple steps, the important questions become registration, delegation, tool scope, and revocation. That makes agent identity governance a practical requirement, not a design preference.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do agentic AI workflows create new IAM risk compared with traditional automation?

A: Traditional automation usually follows fixed rules and predictable paths, so its access model is easier to review. Agentic workflows can choose actions, adapt to signals and trigger downstream systems in real time, which expands the effective trust boundary. That makes role assignment alone insufficient because the identity can accumulate authority through use.

Q: What breaks when organisations treat agent identities like service accounts?

A: What breaks is accountability. Service accounts are usually governed as rigid, task-bound identities, but agents can inherit authority, choose actions, and continue moving through systems at runtime. Treating them the same way hides delegation context and makes it harder to explain why an action was allowed.

Q: What is the difference between an AI agent and a normal automated workflow for security teams?

A: A normal workflow follows predetermined logic, while an AI agent may interpret instructions and choose actions at runtime. That difference matters because the security boundary shifts from a fixed process to a trust relationship that can be manipulated through content, prompts, or delegated context.

Technical breakdown

How MCP and A2A change the trust model

Model Context Protocol gives an LLM structured access to context, tools, and data sources, while agent-to-agent protocols let one agent coordinate with another. Together, they create a trust chain that is longer than a single prompt-response exchange. The risk is not just that an agent can see too much, but that it can carry authority from one step, one tool, or one peer into the next without fresh verification. That is why protocol design and identity design have to be treated as one problem, not two separate ones. Read AI Agents vs Agentic AI.

Practical implication: Define where trust is issued, where it is inherited, and where it must be rechecked before tool use.

Why agent autonomy creates identity sprawl

Agentic systems often rely on multiple moving parts: planners, memory, tools, and execution layers. Each can become a separate control surface, and each can introduce a new credential, token, or delegated permission. That is how identity sprawl appears in AI programmes: not as one agent with one login, but as many artefacts that together create a larger authorisation footprint than teams intended. The governance challenge is to know which component is acting, what it can do, and whether its permissions still match the task.

Practical implication: Inventory every agent-side credential and tie it to a named owner, task, and retirement condition.

Where agent security overlaps with NHI control

In practice, many agent workflows depend on non-human identities such as API keys, service tokens, and short-lived access grants. Those identities are not harmless implementation details. They are the mechanism through which the agent gains real-world effect, and they must be governed as credentials with scope, lifecycle, and revocation requirements. When the article talks about protocols enabling autonomous behaviour, it is also describing the machinery that turns an agent into an active identity-bearing system. That is the point where NHI controls become essential. See the Agentic AI Identity Maturity Model.

Practical implication: Apply NHI lifecycle controls to agent credentials exactly as you would for workloads or service accounts.

NHI Mgmt Group analysis

Agentic AI governance starts with identity, not prompts. The core problem is no longer whether a model can generate a useful answer. It is whether a software actor can obtain, carry, and spend authority in a way that is bounded enough for enterprise governance. Prompt-centric controls miss the real question because the control plane has moved to delegation, tool access, and runtime decision-making. Practitioners should treat the agent itself as the thing being governed.

Delegation trust gap: agent systems often assume that once authority is granted, it can safely persist across the full task chain. That assumption is fragile when a single workflow may span multiple tools, memory lookups, and peer interactions. The stronger the orchestration, the more likely it is that access outlives the original decision to grant it. Security teams should map where delegated access is created, inherited, and terminated.

Protocol choice is now an access-control decision. MCP and A2A are not neutral plumbing choices because they shape how context and authority move between components. If the protocol path is broad, opaque, or weakly scoped, the agent becomes harder to contain even when the model is well behaved. That makes protocol governance part of identity governance, especially where tool access can reach production systems.

NHI controls are the practical bridge between AI orchestration and enterprise security. Agent workflows increasingly depend on secrets, tokens, service credentials, and workload-style identities. Those artefacts should be governed as NHIs with explicit ownership, lifecycle control, and revocation paths, not left inside application code or scattered across orchestration layers. Where a guide exists for this control family, it should be used as the operating model, not a reference appendix.

From our research library:

• The agentic AI market is already worth $5 billion and is projected to reach $50 billion by 2030.
• Read next: Agentic AI Identity Guide

What this signals

Agent identity is becoming the new control point for AI programmes. As adoption accelerates, teams will need a way to distinguish between a model that suggests action and an agent that can actually execute it. That distinction should drive policy design, logging, and approval boundaries, because the risk changes once runtime authority exists.

Delegation trust gap: the security failure mode is not just stolen credentials, but credentials that were valid for the right task and then kept alive after the task changed. As Black Kite’s analysis suggests, identity teams should shift controls toward issuance-time decisions, not only post-use review.

Black Kite’s white paper argues that agentic systems will keep expanding into orchestration layers, which means IAM, PAM, and NHI programmes will need shared rules for ownership, expiry, and revocation. The practical test is whether an agent can be stopped cleanly without breaking the rest of the workflow.

For practitioners

• Map every agent authority path Document which tools, datasets, and external actions each agent can reach, then identify where authority is delegated, inherited, or reissued.
• Separate protocol access from model access Treat MCP or A2A connectivity as a control boundary and require explicit approval for each tool or peer connection the agent can invoke.
• Inventory agent credentials as NHIs Track tokens, API keys, and service credentials used by agent workflows with the same lifecycle controls you apply to workload identities.
• Define revocation triggers before deployment Set conditions that terminate agent access when tasks complete, context changes, or tool scope expands beyond the approved use case.

Key takeaways

• Agentic AI changes the security problem from prompt control to authority control, because the system can take actions rather than only generate text.
• The governance gap is the trust chain between protocols, tools, and delegated credentials, which can outlive the original decision to authorise them.
• IAM and NHI teams should manage agents through ownership, scope, expiry, and revocation so runtime autonomy does not become standing access.

Related NHI Mgmt Group resources: AI Agents vs Agentic AI · Agentic AI Identity Guide · Agentic AI Identity Maturity Model · Agentic AI Security Guide

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
• Identity Sprawl: Identity sprawl is the uncontrolled growth of identities, entitlements, and credentials across an environment. For NHIs, it usually appears when automation creates accounts faster than governance teams can inventory, review, and remove them. The result is hidden access, weak accountability, and a wider attack surface.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security and identity teams apply identity controls to systems that act, not just authenticate.