AI governance frameworks still leave agent identities under-governed

At a glance

What this is: This is an independent analysis of AI governance frameworks and the controls enterprises need to make AI adoption accountable, compliant, and observable.

Why it matters: It matters because IAM, security architecture, and compliance teams now have to govern AI systems that make decisions, use tools, and touch sensitive data, not just approve static access.

By the numbers:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, organisations failing to scope AI access properly are 4.5x more likely to experience a security incident.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 38% have no or low visibility, and a further 47% have only partial visibility.

👉 Read Akto's analysis of AI governance frameworks and responsible AI security controls

Context

AI governance frameworks define the policies, controls, and oversight needed to make AI usable without turning it into unmanaged risk. The problem is that many enterprise programmes still treat governance as documentation and review, while modern AI systems increasingly operate through runtime decisions, tool use, and delegated workflows that need active control.

That creates a direct intersection with IAM, PAM, and NHI governance. When AI agents use static credentials, call APIs, or act through workflow automation, governance has to reach beyond policy statements and into access scope, accountability, logging, and approval boundaries. NHI Mgmt Group's analysis is that this is where most organisations are still underbuilt.

The article's starting point is typical of the market: strong on governance intent, weaker on enforceable technical control.

Key questions

Q: How should security teams govern agentic AI as it moves into production?

A: Security teams should govern agentic AI as a class of non-human identity, not as a generic application feature. That means assigning ownership, scoping permissions tightly, logging every tool action, and revoking access on a defined lifecycle. Production rollout should require clear approval points for high-risk actions and continuous monitoring for drift.

Q: Why do AI agents create a governance problem for IAM teams?

A: AI agents create a governance problem because they authenticate and act as autonomous software entities with tool access. If their actions are logged only as application activity, teams lose accountability, context, and revocation clarity. IAM must therefore extend to agent identity, delegated authority, and control-plane audit trails.

Q: What breaks when AI governance relies only on fixed rules?

A: Fixed rules break when the same model is used by different people for different purposes with different data. They cannot reliably distinguish low-risk productivity from risky disclosure, and they usually miss indirect leakage through summaries or conversational prompts. Contextual governance is needed because risk is situational, not universal.

Q: Which frameworks should organisations use for autonomous AI governance?

A: Use OWASP agentic and LLM guidance for application risk, NIST AI RMF for governance structure, and MITRE ATLAS for adversarial technique mapping. Then translate those frameworks into operational controls that restrict tool access, define approval boundaries, and produce auditable runtime evidence. Frameworks help classify the risk, but enforcement must happen in execution.

Technical breakdown

Policy layer versus runtime control in AI governance

AI governance usually starts with policy: who may use AI, what data it can see, which decisions require oversight, and which risks must be documented. That is necessary, but policy alone does not stop harmful output, tool misuse, or delegated actions once a model or agent is live. Effective governance therefore combines policy with technical enforcement, including logging, access boundaries, and approval gates. In practice, the gap appears when teams can describe the rules but cannot prove the system is following them at runtime.

Practical implication: map every AI policy to a control that can be enforced in production, not just reviewed on paper.

AI agent permissions, tool access, and workflow observability

Agentic systems are different from static models because they can select tools, sequence actions, and continue workflows. That makes permissions design central to governance. If agents inherit broad access, they can cross boundaries faster than human review cycles can react. Workflow observability matters because it shows which tools were called, what data moved, and where decisions were made. Without that traceability, incident response and audit work are reduced to guesswork.

Practical implication: constrain agent permissions to task scope and require end-to-end workflow logging for every delegated action.

Why CI/CD governance matters for AI lifecycle control

Governance fails when it is bolted on after model deployment. AI systems need checks during data ingestion, training, evaluation, release, and change management, because risk can be introduced at any point in the lifecycle. Embedding governance into CI/CD for AI means policy checks, validation, and security testing run before changes are promoted. This is also where NHI concerns appear, because pipelines often rely on secrets, service accounts, and automation identities that can outlive the AI component itself.

Practical implication: treat AI pipelines and their machine identities as part of the governance perimeter, not as separate engineering detail.

Threat narrative

Attacker objective: The objective is to turn delegated AI access into uncontrolled action that affects data, systems, or downstream decisions.

1. Entry occurs through an AI system that is permitted to interact with tools, data sources, or workflows using static credentials or overly broad delegated access.
2. Escalation follows when the system can chain actions beyond the original request, especially where permissions are not scoped to task, context, or approval level.
3. Impact appears as data leakage, unsafe decisions, unauthorized changes, or compliance failure that the governance model cannot explain after the fact.

NHI Mgmt Group analysis

AI governance is becoming an identity governance problem the moment AI systems can act. The article correctly treats governance as policy, accountability, and oversight, but that frame is incomplete unless agent permissions and credentials are brought into scope. Once an AI system can invoke tools or move data, it becomes a governed actor in practice, even if it is not an autonomous system in the strictest sense. Practitioners should treat agent identity and access as part of the governance operating model.

Runtime enforcement matters more than governance language. The strongest policy framework fails if an AI system can still use broad credentials, call sensitive APIs, or complete workflows without logging. This is where NHI governance intersects with AI governance: secrets, service accounts, tokens, and workflow identities become the control surface. The named concept here is governance drift: the gap between policy intent and what the AI stack is actually allowed to do. Practitioners should measure controls at execution time, not just at approval time.

Continuous monitoring is the only credible answer to AI lifecycle risk. AI models change, prompts change, tools change, and downstream behavior changes after release. That means governance must track not only model outputs but also the identities and entitlements attached to training, deployment, and runtime execution. NIST AI Risk Management Framework and CSA MAESTRO are relevant because they both push organisations toward lifecycle accountability, but the operational question is whether access, logging, and review are enforced continuously. Practitioners should assume static review cycles will miss dynamic AI behaviour.

Enterprises are underestimating how much AI governance depends on machine identity hygiene. A governance committee cannot compensate for overprivileged agents, unmanaged secrets, or shared automation accounts. The control model has to cover approval, scope, expiry, and traceability for every identity the AI stack uses. This is the same failure pattern NHI programmes have seen elsewhere: if access is persistent and broad, the governance boundary is already broken. Practitioners should align AI governance with IAM, PAM, and NHI controls rather than running them as separate programmes.

Regulatory alignment will increasingly hinge on evidence, not aspiration. Frameworks such as the NIST AI Risk Management Framework, EU AI Act, and ISO/IEC 42001 all require more than ethical language. They expect traceable oversight, documented risk treatment, and evidence that controls are operating. For identity teams, that means showing who approved what, which identities acted, and how exceptions were contained. Practitioners should prepare for audits that ask for proof of control effectiveness, not just policy existence.

What this signals

AI governance programmes will increasingly be judged by whether they can evidence runtime control over agents, not whether they can publish a policy document. The practical test is whether access scope, approvals, and logging still hold when the model is chained into real workflows. That is why the boundary between AI governance and identity governance is narrowing fast.

Governance drift: the largest risk is not that organisations lack an AI policy, but that the AI stack silently exceeds the policy through broad credentials, unmanaged secrets, or incomplete observability. Teams should expect audit questions to shift from intent to evidence, and from model behaviour to identity behaviour. The control problem is becoming operational, not theoretical.

For identity and AI security teams, the next planning step is to align agent governance with established control models such as the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10. That combination helps translate policy into enforceable scope, review, and monitoring requirements.

For practitioners

• Tie AI policies to enforced identity controls Map every governance rule to a specific control for AI agents, service accounts, tokens, and API access. If the rule cannot be enforced in tooling, it is not a governance control yet.
• Scope agent permissions to task boundaries Limit tool access, data access, and workflow reach to the minimum required for the current job. Reassess scope whenever an agent changes function, data source, or approval path.
• Instrument full workflow observability Log prompts, tool calls, data transfers, approvals, and exceptions so governance and incident response teams can reconstruct what happened. Workflow-level visibility is essential when AI systems chain actions across services.
• Embed governance checks into CI/CD for AI Run validation, security checks, and approval gates before models or agent workflows are promoted. Include secrets handling, model evaluation, and policy enforcement in the same release path.
• Review machine identity hygiene alongside AI governance Inventory every secret, service account, and automation identity used by AI systems. Rotate, expire, and separate those credentials so governance does not rest on persistent shared access.

Key takeaways

• AI governance fails when it stays at the policy layer and never reaches runtime identity and access control.
• The evidence gap is clear: many organisations say AI governance is critical, but far fewer have implemented controls that can actually enforce it.
• Practitioners should govern agent permissions, secrets, and workflow visibility as part of the same programme, not as separate disciplines.

Key terms

• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• 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.
• Governance Coverage Drift: Governance coverage drift is the gap between the access estate an organisation believes it controls and the access estate actually present across applications and identities. It emerges when discovery is incomplete, integrations lag, or review data does not reconcile cleanly to real entitlements.

What's in the full article

Akto's full blog post covers the operational detail this post intentionally leaves for the source:

• Concrete examples of how to structure AI governance across policy, technical, and operational layers
• Implementation detail for runtime guardrails, monitoring, and audit logging in AI workflows
• Security control patterns for agent permissions boundaries and tool access restrictions
• Practical guidance on embedding governance checks into CI/CD for AI systems

👉 Akto's full post covers the governance layers, lifecycle controls, and AI security practices in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and agentic AI identity. It helps practitioners connect identity control to the broader security and governance programmes they already run.