AI governance frameworks still leave agent identities under-governed

At a glance

What this is: This is a governance analysis of agentic AI that finds enterprise AI frameworks still leave agent identity, permissions and workflow controls under-governed.

Why it matters: It matters because IAM, PAM and AI governance teams need controls that govern agent action at runtime, not just policy documents and review cycles.

Context

AI governance is the set of policies, oversight processes and technical controls that constrain how AI systems behave in production. In practice, many frameworks do a reasonable job on accountability and compliance, but they become weaker when the subject is an AI agent that can act, call tools and move through workflows with its own runtime decisions.

That gap matters for identity security because an AI agent is not just a model output layer. When agents hold credentials, interact with APIs or chain actions across systems, the governance problem becomes one of permissions, observability and boundary setting across NHI, agentic AI and human oversight models.

Key questions

Q: What do security teams get wrong about AI agent identity governance?

A: They often assume human IAM patterns can be reused with minor adjustments. That fails because agents can invoke tools dynamically, operate continuously, and combine multiple systems in one session. Governance has to focus on runtime scope, delegated identity, and revocation, not just authentication.

Q: Why do agent permissions create more risk than model outputs alone?

A: Agent permissions expand risk because the harm comes from what the system can do, not only what it can say. A model response can be harmless while a delegated tool call can modify data, trigger transactions or move into another system, so control has to focus on runtime authority.

Q: What signs show that an AI agent is not yet governable?

A: Warning signs include unexplained completions, repeated mistakes after feedback, outputs that cannot be traced to evidence and workflows where operators cannot see intermediate actions. If the agent cannot show what it considered, what it used and how it decided, then the organisation does not have accountability, only a plausible-looking result.

Q: Should teams treat agentic AI access as a PAM or IAM design problem?

A: Both, but the design problem is more specific than traditional PAM. Agentic systems need runtime authorisation at the tool-call boundary, while IAM must define who or what is allowed to initiate those calls. If the decision stays at session setup, the control arrives too early and too broadly.

Technical breakdown

Why policy-first AI governance misses agent permissions

Policy layers define what should be allowed, but they do not by themselves govern runtime access. Agentic systems need explicit identity, authorisation and workflow boundaries because the risk arises when a model can decide which tools to call, when to call them and under what scope. That is closer to dynamic privilege management than static compliance control. Without a control plane for agent permissions, governance remains descriptive rather than enforceable.

Practical implication: treat agent permissions as a live access-control problem, not a policy review exercise.

Runtime guardrails for AI agents and workflows

Runtime guardrails are the point where governance becomes operational. They limit what an agent can output, which tools it can invoke and how far actions can propagate across a workflow. The article’s emphasis on monitoring, audit trails and behaviour controls reflects a broader shift toward enforcing rules at the moment of action, not after the fact. That is especially important where an agent can combine benign steps into a harmful sequence.

Practical implication: enforce task-scoped guardrails that can block unsafe tool use before downstream actions complete.

Workflow observability and auditability in agentic systems

Workflow observability means being able to reconstruct the chain of decisions, tool calls and system actions that produced an outcome. In agentic AI, that is more valuable than generic model logging because the risk sits in the sequence, not just the prompt or response. Auditability also supports accountability, but only if logs capture identity context, authorisation decisions and the full path of delegated actions. Otherwise, the organisation can see that something happened without understanding why it was permitted.

Practical implication: log agent identity, delegated authority and tool calls together so investigations can trace the full decision path.

Threat narrative

Attacker objective: The objective is to exploit delegated agent authority so that trusted automation performs actions outside the organisation’s intended governance boundary.

1. Entry occurs when an AI agent is granted access to tools, data sources or workflows without tightly scoped identity controls.
2. Escalation follows when the agent chains authorised actions into broader access than the original request implied.
3. Impact occurs when the agent completes unintended or non-compliant actions faster than human review can intervene.

Breaches seen in the wild

• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
• Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent identity is now a governance object, not just an implementation detail. Traditional AI governance frameworks were built around oversight of models, data and human decisions. Agentic systems change the question because the system itself can hold and exercise authority through tools, workflows and delegated access. That means identity, authorisation and lifecycle control must sit inside governance, not beside it. The practitioner conclusion is straightforward: if the agent can act, the agent must be governed as an identity-bearing runtime actor.

Workflow visibility is the missing control plane in most AI governance programmes. Many organisations can describe policies for safe AI use, but fewer can reconstruct how an agent moved through a multi-step process. That creates a trust gap between policy compliance and operational reality, especially where AI systems chain actions across APIs, tickets, documents and business systems. The named concept here is agent governance blind spots: governance structures that define intent but cannot observe or constrain the actual delegated action path. Practitioners should close the blind spots before agents become embedded in business-critical workflows.

Runtime control matters more than post-hoc accountability when agents can self-direct tasks. Audit logs and oversight committees still matter, but they do not prevent an unsafe delegation chain from completing. The article aligns with broader NIST AI RMF and ISO/IEC 42001 thinking: governance must be operationalised through measurable controls, not abstract principles alone. For identity teams, the implication is that agent permissions, approval thresholds and tool-access scope should be designed as first-class governance controls.

AI governance and IAM are converging around delegated authority. Once agents interact with enterprise systems, the boundary between AI governance and access governance disappears. That creates a shared responsibility model for security, legal, compliance and platform teams, but the technical ownership has to land somewhere concrete. The practitioner conclusion is that IAM and AI governance teams should jointly define how agent identity is issued, constrained, monitored and revoked.

Human oversight without machine-boundary controls becomes a reassurance, not a safeguard. Many frameworks still assume a human can catch misuse before harm occurs. Agentic AI breaks that assumption because actions can happen faster than human review and within delegated business flows. The field needs to move from supervision as a principle to supervision as an enforced control boundary. Practitioners should treat human-in-the-loop requirements as one layer, not the whole governance model.

From our research library:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Half of companies using generative AI will deploy agentic AI by 2027, according to Deloitte's 2025 Technology Predictions.
• Read next: Agentic AI Identity Maturity Model

What this signals

Agent governance blind spots: the most material risk is not whether AI policy exists, but whether an agent can exercise delegated authority outside the review path that policy assumes. For practitioners, that means the control boundary has to move from governance documents into issuance, authorisation and runtime enforcement.

The operating model is shifting toward platform teams, infrastructure teams and security teams sharing responsibility for AI control, which makes clear ownership more important than broader principle statements. According to the 2026 Infrastructure Identity Survey, 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite.

For identity programmes, the practical signal is simple: if agent identity, tool scope and workflow traceability are not visible in the same control plane, auditability will lag behind adoption and incidents will be harder to contain.

For practitioners

• Define agent identities separately from user identities Create distinct identity records, ownership, and lifecycle rules for AI agents, including who approves access, who can revoke it, and which systems each agent may touch.
• Scope tool access to task-specific boundaries Limit each agent to the minimum tools, APIs, and data sources needed for a single workflow, and require explicit approval for anything outside that task boundary.
• Instrument workflow-level observability Capture agent identity, tool calls, decision paths, and delegated actions in logs so teams can reconstruct how an outcome was produced end to end.
• Add runtime guardrails before deployment Block unsafe prompts, unauthorized tool use, and policy-breaking actions at execution time rather than relying only on offline review or periodic audits.
• Reconcile AI governance with access governance Map AI approval thresholds, ownership, and incident response steps to existing IAM and PAM controls so delegated authority is governed consistently across teams.

Key takeaways

• AI governance frameworks still leave a practical gap when agents can hold identity, call tools and move through workflows under delegated authority.
• That gap is less about policy language than about whether runtime permissions, observability and revocation are strong enough to control agent behaviour.
• Identity and access teams need to treat AI agents as governed actors, with lifecycle, scope and audit controls that operate at execution time.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
• Workflow observability: Workflow observability is the ability to see where a business process is, what system owns the next step and why an exception occurred. For digital agreements, it is the difference between managed automation and invisible fragmentation that falls back to manual handling.
• 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.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity and machine identity security. It helps practitioners align identity controls with the realities of delegated access and runtime decision-making.