By NHI Mgmt Group Editorial TeamPublished 2026-05-04Domain: AI SecuritySource: Drata

TL;DR: McKinsey’s 2026 AI Trust Maturity Survey found two-thirds of organisations are experimenting with AI agents, but fewer than one in four have scaled them to production because trust, security, and risk concerns remain the main barrier. The operational bottleneck is no longer model capability, but governance, permissions, and auditable control across agent actions.


At a glance

What this is: This is an independent analysis of why trust, auditability, and governance are now the limiting factors for enterprise AI agents.

Why it matters: It matters to IAM and security teams because agentic systems create identity, privilege, and accountability problems that traditional controls were not designed to track continuously.

By the numbers:

👉 Read Drata's analysis of AI agent trust, governance, and compliance


Context

AI agent adoption is colliding with a governance gap. The models can already act, but enterprises still lack the permissions, audit trails, and accountability structures needed to control those actions safely. For IAM and security teams, that makes agent identity, access scope, and proof of behaviour the real operational problem, not model novelty.

The article frames trust as the scarce control point in an AI-driven operating model. That intersects directly with NHI governance because agents are software entities that can request access, modify systems, and create drift at machine speed. The starting position here is increasingly typical for enterprises experimenting with agentic AI, but still atypical for organisations that have already built audit-grade control layers.


Key questions

Q: How should security teams govern AI agents that can take actions on their own?

A: Security teams should govern AI agents as machine identities with explicit owners, narrow entitlements, runtime policy checks, and immutable audit trails. The key is to control what the agent can do at the moment it acts, not just to approve the model or the deployment once. Without that, accountability and containment both fail.

Q: Why do AI agents create problems for traditional IAM and audit processes?

A: Traditional IAM assumes identities are relatively stable and that access can be reviewed after use. AI agents can make decisions, call tools, and change state within the same runtime session, which compresses the window for review and makes stale entitlement thinking insufficient. Audit processes must move to action-level verification.

Q: What breaks when AI agent permissions are not tightly scoped?

A: When agent permissions are too broad, the agent can drift from the task it was meant to perform into configuration changes, data access, or privilege changes that were never intended. That expands blast radius and makes containment harder because the system cannot easily distinguish legitimate delegation from unsafe overreach.

Q: Who is accountable when an AI agent causes a security or compliance issue?

A: Accountability should sit with the business owner of the agent workflow, the security team that approved the control model, and the platform team that enforced runtime policy. If those responsibilities are not assigned up front, organisations will struggle to explain why the agent was allowed to act and how its behaviour was verified.


Technical breakdown

Why AI agents create an identity and privilege problem

An AI agent is not just a model. It is a software system that can choose actions, call tools, and interact with data sources at runtime, which means it behaves like a non-human identity with operational consequences. Once an agent can configure systems, modify access, or deploy infrastructure, the control question shifts from whether the model is accurate to whether its privileges are scoped, bounded, and observable. Traditional IAM often treats identities as durable actors with stable roles, but agentic systems can change context rapidly and trigger actions outside human review cycles. That is where governance, PAM, and audit design become inseparable.

Practical implication: treat agents as governed identities with explicit access scope, not as benign automation.

Audit trails and permissions are the real trust layer

The article’s central technical point is that trust in agentic AI depends on orchestration, permissions, and audit systems, not on model capability alone. An enterprise can only trust an agent if it can answer what data the agent accessed, what actions it took, what policy allowed those actions, and who is accountable when behaviour drifts. That is an identity governance problem as much as an AI problem. The missing layer is durable evidence: policy enforcement at action time, immutable logging, and reviewable provenance that ties each agent action back to a specific identity and entitlement.

Practical implication: require policy-enforced logging for every privileged agent action before production rollout.

Why agent drift breaks human-paced controls

Agents can create configuration changes, access changes, and infrastructure changes faster than human monitoring cycles can catch. That makes them difficult to govern with controls that assume discrete tickets, scheduled reviews, or delayed approvals. In practice, this is a form of control latency: the time between an action occurring and a human being able to validate it is too long to preserve confidence. When agents can chain decisions and act continuously, the control model has to shift toward real-time enforcement, bounded delegation, and automatic rollback. Without that, the audit layer becomes retrospective only, which is too late for containment.

Practical implication: replace periodic review assumptions with runtime guardrails and rollback-ready enforcement.


NHI Mgmt Group analysis

AI agent trust is becoming the new identity control plane. The article is right to frame trust as the scarce resource, because the hard problem is not model intelligence but governable machine action. Once agents can access systems and change state, identity governance must extend from human users to software decision-makers. Practitioners should treat agent identity as a first-class control domain, not a side effect of AI deployment.

Governance debt is now an AI security risk. Enterprises that rushed into experimentation without an audit and permission model are accumulating unreviewable actions, unclear accountability, and inconsistent policy enforcement. That creates a compounding gap between what the organisation thinks the agent can do and what it can actually do. The practical conclusion is that trust has to be engineered into the operating model before scale, not added after adoption.

Trust centres are only useful if they are connected to runtime control. A visible trust posture is not enough when agents can alter configurations or privileges in real time. The article points toward continuous proof, which aligns with the broader shift in identity and security toward verifiable action rather than static approval. Practitioners should require evidence that trust controls are enforced where the action occurs, not only where the report is generated.

Agentic AI exposes the limits of periodic access review. Access reviews assume identities remain stable long enough to be evaluated. Agent workloads can make, consume, and discard access within a single business process, which means stale entitlements are not the only issue. The governance challenge is proving that each delegated action stayed inside policy at the moment it happened, and that demands machine identity controls, not just human IAM workflows.

Named concept: trust infrastructure layer. The article describes a layer that verifies agent actions continuously, links them to policy, and makes them auditable in real time. That concept matters because it turns trust from a brand promise into a control architecture. Practitioners should view this as the missing bridge between AI capability and enterprise accountability.

What this signals

Trust latency is now a programme-level risk. If AI systems can act faster than your review and containment loops, the security issue is not model quality but control latency. Teams should expect pressure to move from periodic assurance to runtime enforcement, with stronger integration between IAM, PAM, and policy engines.

The most effective programmes will separate model governance from action governance. That means proving not only that the model is approved, but that every tool call, permission grant, and state change is observable, attributable, and reversible. Organisations that do this will be able to scale agentic use cases without handing control to opaque automation.

For identity teams, the next phase is less about adding another dashboard and more about building a runtime delegation boundary: a place where agent action is authorised, logged, and bounded in the same control plane. That is the operational difference between experimentation and enterprise-grade trust.


For practitioners

  • Define agent identities explicitly Assign each AI agent a unique identity, scoped entitlements, and an accountable owner before it can access production systems or customer data.
  • Enforce runtime policy checks Require every privileged agent action to pass policy validation at execution time, not after the fact, so drift is blocked before it propagates.
  • Instrument immutable action logging Capture who or what the agent was, what tool it called, what data it touched, and what outcome it produced in logs that support audit and incident review.
  • Limit delegated access by task Use time-bounded, task-scoped access for agent workflows and revoke privileges automatically when the workflow ends or changes context.
  • Build rollback for agent-caused changes Design controls so configuration, access, and deployment actions taken by agents can be reversed quickly when the agent exceeds policy or produces unsafe output.

Key takeaways

  • AI agent trust is a governance and identity problem, not just a model performance problem.
  • Without runtime permissions and audit trails, agent actions can outrun human-paced review and create unbounded drift.
  • Enterprises that want to scale agentic AI need policy enforcement, bounded delegation, and reversible action controls before production rollout.

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 address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST AI RMFGOVERNThe article centres on accountability and governance for AI systems.
OWASP Agentic AI Top 10Agent tool access, autonomy, and auditability are core concerns here.
NIST CSF 2.0PR.AC-4Agent identity and least-privilege access map directly to access control governance.
NIST SP 800-53 Rev 5AC-6Least privilege is the most direct control for limiting agent blast radius.

Map agent entitlements to PR.AC-4 and restrict access to the minimum required for each workflow.


Key terms

  • Agent Identity: The unique identity assigned to an AI agent so it can be governed like any other software actor. It ties the agent’s runtime actions to an owner, an entitlement set, and an audit trail, making delegated activity accountable and reviewable.
  • Trust Infrastructure Layer: The control layer that verifies whether an AI system behaved within policy, can prove what it did, and can surface drift in real time. In practice, it combines permissions, logging, oversight, and evidence so machine action becomes auditable rather than opaque.
  • Runtime Delegation Boundary: A control boundary that limits what an agent may do while it is executing a task. It is narrower than a broad role assignment because it binds access to context, duration, and policy, reducing the chance that delegated machine action becomes uncontrolled privilege.

What's in the full article

Drata's full article covers the operational detail this post intentionally leaves for the source:

  • How Drata positions trust centres, compliance automation, and assurance workflows in an agentic operating model.
  • The operational story behind continuous proof, audit readiness, and control monitoring for AI-driven systems.
  • The specific enterprise use cases Drata highlights for regulated environments such as healthcare, finance, and education.
  • The product and workflow detail behind its trust infrastructure layer for agent action verification.

👉 The full Drata article expands on trust infrastructure, auditability, and the control model for agentic systems.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It gives security and identity practitioners a practical foundation for governing software identities across modern enterprise environments.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-05-04.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org