AI compliance frameworks are breaking under agentic runtime drift

At a glance

What this is: This analysis argues that AI compliance frameworks must move from point-in-time policy mapping to continuous, runtime enforcement because agentic systems can drift beyond their intended scope.

Why it matters: It matters because IAM, security, and governance teams now have to control AI systems whose permissions, tool use, and behaviour can change after deployment, not just at provisioning.

By the numbers:

• The EU AI Act full enforcement arrives August 2, 2026.

👉 Read Lasso Security's analysis of AI compliance frameworks for agentic systems

Context

AI compliance frameworks define the policies, controls, and evidence required to keep AI systems within declared risk boundaries. In practice, that becomes difficult when agentic AI can select tools, chain actions, and move across systems after deployment, because the governance model is no longer dealing with a static system boundary.

The central governance problem is runtime drift. A system may remain compliant against a documented rule set while still acting outside the intent behind its permissions, which leaves IAM, legal, and security teams with controls that look complete on paper but fail under autonomous execution.

That gap is why AI compliance now sits alongside identity governance, not outside it. Discovery, classification, access scope, audit evidence, and runtime enforcement all become part of the same control plane when AI systems can act across tools, data, and other agents.

Key questions

Q: How should organisations govern AI systems that can change scope at runtime?

A: They should treat runtime behaviour as part of the compliance boundary. That means inventorying every model, tool, and integration, then checking whether the system still acts within its intended purpose after deployment. Static approval is not enough when an agent can expand scope through chained actions or delegated workflows.

Q: Why do agentic AI systems break traditional compliance frameworks?

A: Because traditional frameworks assume permissions, intent, and accountability remain stable long enough to be reviewed. Agentic systems can select tools, trigger sub-actions, and drift from purpose inside a single session, so point-in-time policy evidence can say the system is compliant while its behaviour is not.

Q: What do security teams get wrong about AI compliance evidence?

A: They often collect evidence after the fact instead of building it into the control path. For agentic systems, logs of actions, classification records, remediation trails, and oversight checkpoints need to be captured continuously, or there is no reliable way to reconstruct what happened.

Q: Who is accountable when an autonomous AI system acts outside its intended scope?

A: Accountability must be assigned before the system goes live, and it has to include ownership for runtime behaviour, not just deployment. If an AI system can cross tool boundaries or spawn delegated actions, governance has to name the responsible control owner and the escalation path in advance.

Technical breakdown

Why static AI compliance breaks at runtime

Traditional compliance programs assume that policy definition, access assignment, and verification happen in a stable sequence. Agentic AI breaks that sequence because tool use, memory, and delegated actions can change during execution. A system may start within policy and then shift scope through multi-step interactions, chained prompts, or new tool connections. That creates a gap between declared compliance and actual behaviour. In identity terms, the problem is not only whether access was granted, but whether the permission model still describes what the system is doing after it begins acting.

Practical implication: treat runtime behaviour as part of compliance evidence, not just deployment-time configuration.

Why intent-based enforcement matters for agentic AI

Intent-based enforcement is different from rule checking. Rule checking asks whether a specific action was allowed. Intent-based enforcement asks whether the sequence of actions still matches the purpose for which the system was authorised. That distinction matters when an agent can perform multiple sub-actions that individually look valid but collectively achieve something no human explicitly approved. This is where compliance, security, and access governance converge: the control problem is no longer just entitlement, but behavioural alignment over time.

Practical implication: map policies to intended use, then test whether live agent behaviour stays within that intended use.

Why the AI supply chain becomes a compliance surface

AI systems inherit risk from models, tools, integrations, and third-party connections. If any of those components can add capabilities, change behavior, or expand data access, then the compliance boundary must include the supply chain. That is especially true for MCP servers, external model updates, shadow deployments, and agent-to-agent dependencies. Governance that stops at the application layer misses the place where many real control failures begin: uncontrolled expansion of what the system can reach and do.

Practical implication: inventory every model, tool, and integration as part of the compliance scope, not as adjacent infrastructure.

Threat narrative

Attacker objective: The objective is to make the AI system execute actions that remain formally permitted step by step while violating the real intent of its authorisation model.

1. Entry occurs when an AI system is granted legitimate access to tools, data, or other agents as part of normal deployment or integration.
2. Escalation happens when the system drifts from its intended scope through chained actions, new connections, or delegated sub-agent behaviour.
3. Impact follows when the system performs actions outside the original approval boundary, leaving weak audit trails and limited containment options.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI compliance has become an identity governance problem, not just a legal one. Once an agent can act across tools, data, and delegated workflows, the question is no longer whether a policy exists. The question is whether identity, privilege, and audit controls still describe the system after it starts operating. That makes AI compliance inseparable from NHI governance, runtime access scope, and evidence capture. Practitioners should stop treating AI compliance as a separate policy stack and start treating it as part of the identity control plane.

Policy written for static systems cannot govern autonomous execution without assumption collapse. The assumption that permissions remain stable long enough to be reviewed was designed for human-paced or service-paced access. That assumption fails when an agent can trigger cascades of actions, create sub-agents, or alter scope mid-session before a review cycle can ever observe the state. The implication is not simply that more controls are needed. The assumption itself no longer holds, and governance must be redesigned around runtime behaviour.

Runtime drift is the named failure mode this article exposes. An AI system can stay inside its granted permissions while still moving outside its intended purpose through repeated low-risk actions, delegated steps, or tool-chain expansion. That is a governance failure because the compliance model is measuring the wrong unit of control. Practitioners should focus on behavior, not just entitlement, when deciding whether an AI system remains compliant.

The AI supply chain is now part of the compliance boundary. Models, MCP connections, shadow deployments, and third-party integrations can change what an AI system is able to access long after initial approval. That creates a governance surface that looks like ordinary integration management until it expands into behavioural risk. Security teams should treat every new tool connection as a compliance event, not an implementation detail.

Continuous evidence is the only defensible audit posture for agentic systems. Point-in-time documentation cannot prove what an autonomous system did between review cycles. Logs of agent actions, remediation trails, risk classifications, and human oversight points are now the minimum evidence set for regulated AI use. Practitioners should build evidence collection into the control path, not into after-the-fact reporting.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to the 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
• That pattern is why teams should pair discovery with governance, using the NHI Lifecycle Management Guide and the Top 10 NHI Issues to tighten lifecycle and access control.

What this signals

Runtime drift will become the decisive compliance signal for AI programmes. If a system can remain within policy on paper while moving outside intent in operation, then compliance owners need behavioural telemetry, not only configuration review. That shift also changes how teams think about lifecycle control across agents, service accounts, and human oversight. The relevant benchmark is not whether a policy exists, but whether the system can still be observed and constrained after execution begins.

AI compliance will increasingly converge with identity lifecycle governance. The same control logic that governs provisioning, privilege scope, and offboarding for non-human identities now has to account for agents whose permissions and actions change while they are active. With 46% of organisations already confirming a non-human identity breach and another 26% suspecting one, the governance baseline is no longer theoretical. Practitioners should prepare for compliance questions that ask how access is revoked, not just how it was approved.

Continuous evidence collection is becoming a design requirement, not a reporting task. Teams that still separate AI monitoring from audit evidence will struggle to answer basic regulator and board questions. For practitioners, the practical next step is to align runtime enforcement with the NHI Lifecycle Management Guide so lifecycle events, scope changes, and closure actions produce a defensible record.

For practitioners

• Inventory every AI system and tool connection Create a live catalogue of models, agents, MCP connections, shadow deployments, and delegated integrations. Include permissions, data flows, and ownership so compliance teams can see scope changes as they happen.
• Map permissions to intended use, not only allowed actions Review whether each system's live behaviour still matches the business purpose for which it was approved. Document where repeated low-risk steps, sub-agent creation, or tool-chain growth drift outside that intent.
• Collect runtime evidence as a control requirement Store agent action logs, classification records, remediation trails, and oversight checkpoints in one evidence path. Use that record to support audit readiness when regulators or internal reviewers ask what the system actually did.
• Treat third-party model updates as governance changes Reclassify systems when providers change behavior, memory handling, or tool access. A model update can alter the compliance boundary even if the application code stays unchanged.
• Tie red teaming to policy updates Run adversarial tests against single-turn and multi-turn attack paths, then feed findings directly into runtime enforcement and policy revision. Testing that does not change controls only documents exposure.

Key takeaways

• Agentic AI exposes a compliance gap that traditional static controls were never built to close.
• The evidence problem is now operational: if runtime behaviour is not logged, compliance cannot be proven.
• Security teams should govern AI systems as living identity subjects whose scope, purpose, and audit trail must be continuously controlled.

Key terms

• AI Compliance Framework: A structured set of policies, controls, and evidence practices used to keep AI systems within legal, operational, and risk boundaries. For agentic systems, it must cover runtime behaviour, not just deployment approval, because the system can change what it does after access is granted.
• Runtime Drift: The condition where an AI system begins operating outside the intent behind its approved permissions while still appearing compliant at the action level. In practice, this shows up when individually valid steps combine into a broader outcome that no human explicitly authorised.
• Intent-Based Enforcement: A control approach that checks whether live system behaviour still matches the purpose for which the AI was authorised, not only whether a single action was allowed. It is especially important for agentic AI because step-by-step permissions can hide larger policy violations.
• AI Supply Chain: The set of external models, tools, integrations, and connections that influence what an AI system can access and do. For compliance, the supply chain matters because changes in third-party components can expand scope, alter behavior, or create new audit obligations without changing application code.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Lasso Security: AI Compliance Framework: Key Components, Challenges & Best Practices. Read the original.