Agentic AI Compliance: How to Secure, Govern and Monitor AI Agents

A chatbot can give you a bad answer. An agent can make a bad decision and execute it.

For years, adding AI to a website meant adding a chatbot. A visitor typed a question. The model generated an answer. The conversation ended.

That architecture is changing.

AI assistants are moving into websites, e-commerce platforms, CRMs, support systems, internal tools, scheduling systems and financial workflows. They are no longer limited to generating text. They can search databases, call APIs, update records, create tickets, modify orders, trigger workflows, and in some cases initiate transactions.

The moment an AI system can act rather than respond, the architecture changes. So does the compliance problem.

A chatbot gives a bad answer. An agent executes a bad decision.

The argument of this article runs in one direction, and it is worth stating before anything else.

AI agents are becoming part of business architecture rather than sitting alongside it. Because they are, compliance can no longer live in policy documents. It has to become architectural, for the same reason that access control and audit logging did.

Compliance here is not the subject. It is the consequence.

From Answering to Acting

From Answering to Acting

Agentic AI compliance is the practice of designing, deploying and monitoring AI agents so that their autonomous actions remain within defined legal, organisational, security and operational boundaries.

The important word is actions.

Traditional AI governance focused on the model and its outputs. Is it accurate? Is the training data appropriate? Does it produce biased results? Can its output be explained? Those questions remain important.

An agent introduces another layer entirely. What systems can it access? What tools can it use? What decisions can it make? What can it change? Who authorised it? When does it need a human? Can the organisation reconstruct what happened?

This is why agentic AI compliance is not simply an AI policy problem. It is increasingly a software architecture problem.

Two architectures

The difference can be illustrated simply.

A traditional AI assistant runs user → model → response. The model receives information and generates something for the user.

An agentic system runs user → agent → reasoning → tool selection → API → business system → result → next action. The AI is now operating inside a larger system.

Consider customer service. A traditional chatbot answers: "Your order is currently being processed." An agentic assistant can identify the customer, access the order system, inspect the order, determine that it qualifies for a refund, create the refund request, update the CRM, notify the customer and record the transaction.

The second system is far more useful. It is also much harder to govern.

If the refund is wrong, the problem is no longer that the AI generated an incorrect sentence. A business process has changed.

The moment permissions appear

Most AI compliance discussion still assumes the AI produces content. Once the AI can act, the questions become operational.

An agent in a retail environment might read a customer record, update an order, apply a discount, change a price, adjust inventory, issue a refund, or write to the catalogue. Each of those is a permission, and each permission is a decision somebody made, deliberately or by default.

Every capability an agent has was granted by someone.

That is the shift. Compliance stops being a document and becomes a property of the system.

Three Different Questions

Three Different Questions

Three terms get used interchangeably and should not be.

AI governance asks what the AI system should be allowed to do. It is a policy question, answered by people.

AI security asks whether someone can compromise or misuse the system. It is a threat question, answered by defences.

Agentic AI compliance asks whether the system, as built, actually enforces the first and survives the second, and whether the organisation can prove it afterwards.

The third depends on the first two and is not satisfied by either. A well-governed agent with no technical enforcement is an intention. A well-secured agent with no policy is a fast way to do the wrong thing reliably.

The Control Stack

The Control Stack

A production agent needs five layers, and each answers a different question.

1. Identity

Who is acting? Not which model, but which identity the action is attributed to. An agent acting on behalf of a user is a different thing from an agent acting as a service account, and the audit trail has to distinguish them.

2. Authorization

What is that identity allowed to do? This is where least privilege applies, and where most implementations stop.

They should not, because privilege is only half the question.

Least privilege controls access. Least agency controls decisions.

Least privilege controls what the agent can reach. Least agency controls how much freedom it has to decide what to do with it. An agent can have narrow database permissions and still have far too much latitude in choosing when to use them.

3. Tools

Tools define the real surface of an agent. Not the model, not the prompt, the tools.

The distinction matters more than it sounds. Reading a product catalogue and modifying a product catalogue are different capabilities. Creating a refund request and executing a refund are different capabilities. In a multi-market store, changing a price in one market and changing it everywhere are different capabilities, and a tool that does not distinguish them has already made a decision nobody reviewed.

4. Policy outside the model

Instructions in a prompt are not controls. They are requests.

The architecture that works places a policy engine between the agent and production: agent → policy engine → authorised tool → business system.

Instructions influence behaviour. Controls enforce behaviour. An agent asked politely not to issue refunds above a threshold will usually comply. A system that cannot issue them always will.

5. Evidence

Every meaningful action needs a record that answers: who acted, what they did, when, why, under what authority, using which tool, against which system, and what happened afterwards.

Not because an auditor might ask. Because when something goes wrong, that record is the only way to find out what actually happened.

Who Is Responsible

Who Is Responsible

Once an AI system can take action, regulation becomes more complicated, though not for the reason most people assume.

Regulators did not create a special category called "AI agents." The European Commission's AI Act Service Desk states it directly: while AI agents are not a separate category of AI under the AI Act, the existing definitions of an AI system and of a general-purpose AI model are sufficient to cover them.

The applicable requirements therefore depend on what the system does, how it is used, who operates it, and which regulatory category applies.

Calling something an agent does not make it high-risk. But giving an AI system the ability to decide and execute creates serious operational, security and accountability questions regardless of what it is called.

The question is not what it is called. It is what it can do.

What applies and when

The Service Desk sets out a timeline that is worth knowing precisely, because the obligations do not arrive together.

The AI Act's prohibitions on harmful manipulation and exploitation of vulnerabilities are already in force, and the Commission notes that compliance may require safeguards in the design of agents specifically.

From 2 August 2026, transparency rules apply where an agent is intended to interact with people or generate content.

From 2 December 2027 and 2 August 2028 respectively, agents classified as high-risk systems become subject to the additional requirements of Chapter III.

Separately, for the underlying models, the Commission notes that the level of autonomy and tool use can be decisive in whether a general-purpose model is designated as carrying systemic risk.

One more point deserves emphasis, because it is unusual for a regulator to say it plainly. The Commission describes its own regulatory considerations on AI agents as preliminary at this stage, with the AI Office continuing to monitor developments.

That is not a reason to wait. It is a reason to build systems whose controls can be demonstrated regardless of how the classification settles.

What this actually changes for a build

Read practically rather than legally, the regulatory picture asks a company building an agent for three things.

It has to know what its agent does and can affect, in enough detail to classify it. It has to be able to show that the classification is correct. And it has to produce evidence that the controls it claims to have were operating.

All three are architectural properties, not documents. A system that cannot answer them has a compliance problem regardless of which regulation applies to it.

Transparency obligations sit alongside this and are frequently mistaken for the whole of it. Telling a user they are interacting with AI does not answer what the agent can access, which tools it can use, what requires approval, or how an incident can be investigated.

Transparency tells people something about the system. Governance controls what the system can do.

Three Layers of Risk

Three Layers of Risk

Risk in an agentic system is easier to reason about in layers, because the failures at each level look different and are caught by different controls.

Model risk is the familiar one. The model is wrong, biased, or confidently mistaken. This is where most AI governance discussion still lives.

Agent risk appears when the model is right and the agent still does the wrong thing. It selects the wrong tool, pursues a misread goal, or acts on information that should not have been trusted, a problem we examined separately in The Cost of AI Isn't Generation. It's Verification.

System risk is what happens next. The action propagates. An order changes, an integration fires, another workflow reacts, a notification goes out. The question here is not whether the AI was correct but what the business impact of the failure is.

Risk travels as a chain

These layers are not independent. A small model error becomes an agent decision, which becomes a system change, which becomes a business consequence.

The chain runs input → interpretation → decision → tool → authorisation → system change → downstream effect, and a control placed anywhere along it limits everything after.

A model error is a sentence. A system error is a transaction.

This is why the useful question is not how accurate the model is, but how far a mistake can travel before something stops it.

Eight Ways Agents Fail

Eight Ways Agents Fail

1. Excessive agency

The agent simply has too much freedom. If an assistant only needs to retrieve information, there may be no reason to let it modify records. If it needs to modify one field, there is no reason to grant write access to an entire database.

Every additional capability increases the blast radius. The safest agent is not the least intelligent one. It is the one whose autonomy is proportional to the task.

2. Excessive privilege

An agent inherits broad permissions because issuing a powerful service account is easier than designing granular authorisation.

This creates a mismatch worth stating explicitly: business responsibility is not the same as technical privilege. A support agent should not inherit administrator access because that was the credential available.

3. Tool misuse

Every tool an agent can reach becomes part of its failure surface. An agent with search, email, CRM, payments and file storage may be authorised to use all of them. That does not mean every tool should be available for every task.

A better architecture exposes tools conditionally. A support agent might read an order, update a ticket and draft a response, but not execute a refund unless a policy condition is satisfied.

In commerce this matters more than it first appears. An agent that can write to a product catalogue can, in principle, change a price. An agent that can change a price in a multi-market store can, in principle, change it in markets nobody was looking at.

4. Goal hijacking

Agentic systems work toward goals rather than executing single deterministic commands, which makes goal manipulation a distinct category of attack.

It can arrive through malicious user input, poisoned documents, compromised websites, injected instructions, manipulated tool output or retrieved content. The dangerous part is that the agent then uses entirely legitimate capabilities to pursue the wrong objective.

This is different from a traditional vulnerability. The system may be functioning exactly as designed.

5. Memory and context poisoning

Agents that retain context carry their errors forward. A false fact accepted once can inform decisions for the rest of a session, or longer where memory persists.

The failure is quiet, because nothing broke. The agent simply believes something that is not true and acts consistently on it. We wrote about how convincingly that can happen in Four AIs Agreed. We Still Hadn't Verified Anything.

6. Cascading failures

One agent calls an API, which triggers a workflow, which invokes another agent, which writes to a database, which fires a notification.

The chain agent A → API → workflow → agent B → database → notification is efficient when correct and difficult to unwind when not. Each step was authorised. The combination was not reviewed by anyone.

7. Identity and privilege abuse

In an agentic system, several identities are in play at once: the human user, the agent, the service account, and whatever external system is called. When the audit trail collapses them into one, accountability disappears.

The trail should preserve the whole path: user → agent → workflow → tool → authorisation → system change.

8. Human-agent trust exploitation

The last failure is social rather than technical. People approve what the agent proposes because it is usually right, and approval becomes a formality.

An approval step that is always clicked through is not oversight. It is a log entry.

Oversight should follow risk

Human involvement should scale with consequence rather than being applied uniformly.

• Low risk: autonomous execution is reasonable
• Moderate risk: restricted permissions and monitoring may be sufficient
• High risk: human approval may be required
• Critical or irreversible: the system may need to prohibit autonomous execution entirely

Autonomy should decrease as irreversibility increases.

Why Commerce Is Harder

Why Commerce Is Harder

The failures above apply anywhere. They are sharper in e-commerce for a specific reason: the systems an agent touches are the ones that hold prices, stock and money, and most of what they hold is customer-facing within seconds.

Consider what a single connection actually grants. An agent with write access to a product catalogue can, in principle, change a price, change availability, rewrite a description, alter market-specific content, launch a promotion, adjust inventory or trigger a refund.

Those are seven distinct commercial decisions arriving through one integration, and most catalogue APIs do not distinguish between them.

One integration. Seven commercial decisions. No distinction between them.

The multiplier problem

Multi-market stores make this materially worse, and for reasons that have nothing to do with AI.

In a store selling across several countries, a product does not have one price, one stock figure and one description. It has one of each per market, and those states have to stay consistent with each other. We wrote about that separately in Multi-Country E-Commerce for Large Catalogues.

Now introduce an agent. A price change that would have been one action in a single-market store becomes a decision about which markets it applies to, and an agent that does not model that distinction will make it implicitly.

An agent authorised to change a price is authorised to change it somewhere. Whether that means one market or eight is an architectural decision, and if nobody made it, the tool made it.

Speed removes the safety margin

Commerce systems are also unusually unforgiving about time.

An incorrect price is live immediately, visible to customers, and picked up by feeds, comparison sites and ad platforms within minutes. An incorrect stock figure is a promise the business cannot keep. A refund is money that has left.

The window between a wrong decision and a business consequence, which in most software is measured in review cycles, is here measured in seconds.

Which controls actually matter here

Three of the earlier controls carry disproportionate weight in a commerce environment.

Narrow tools, because updateProductDescription and updateProductPrice should never be the same capability. Market scope as an explicit parameter, so that "which markets" is a decision the system requires rather than a default it assumes. And reversibility as a design constraint, because a description can be restored, a price that was live for an hour cannot be un-published from a competitor's price tracker.

None of this argues against putting agents into commerce systems. It argues for deciding what they may touch before connecting them, which is cheaper at the design stage by a wide margin.

Monitoring and Evidence

Monitoring and Evidence

Monitoring an agent is not monitoring an application, because the failure modes are different.

A traditional system fails by erroring. An agent fails by succeeding at the wrong thing. Every API call returns 200. Every integration works. The business outcome is still wrong.

A successful API call does not mean a successful business action.

What to track

Useful monitoring covers functional behaviour, tool behaviour, authorisation behaviour, data behaviour, policy behaviour, behavioural anomalies, human interventions and business outcomes.

The last one is the one most often missing, and the only one that catches an agent that is quietly doing something legal, authorised and wrong. The same trust question, applied to content rather than actions, is covered in Human-First Content Strategy.

Auditability is not logging

Logs record that something happened. An audit trail reconstructs why.

For a single refund, a usable trail answers: which customer, which user initiated it, which agent handled it, what information the agent used, which policy allowed the operation, which credentials were used, what amount, whether approval was required, whether it was obtained, what the external system returned, and what the final state was.

The purpose is not to satisfy a checklist. It is to produce useful evidence.

Automation enforces policy, it does not decide it

Parts of compliance can be automated: inventorying systems, collecting logs, checking permissions, detecting anomalies, enforcing policies, generating reports.

But automation can enforce that refunds above a threshold require approval. It cannot determine whether the refund policy is appropriate. It can detect that an agent accessed restricted data. It cannot decide whether that access was justified.

Automation enforces and demonstrates defined policies. People remain responsible for defining them and for judging ambiguous cases.

Frameworks Are Not Architecture

Frameworks Are Not Architecture

A useful way to think about an agentic system:

Compliance = Policy + Authority + Controls + Evidence + Oversight

Policy is what should happen. Authority is who or what may make it happen. Controls are what technically prevents unauthorised behaviour. Evidence is whether it can be proven afterwards. Oversight is where a human can intervene.

Remove any one and the system weakens in a specific, predictable way.

The translation problem

Organisations now have access to genuinely useful frameworks. The EU AI Act provides a legal, risk-based structure. NIST offers guidance on trustworthy AI. OWASP publishes practical security guidance for agentic applications.

None of them turns an agent into a compliant production system, because each states principles rather than mechanisms. The engineering work is the translation:

• policy becomes authorisation
• risk becomes permission
• oversight becomes an approval workflow
• auditability becomes a structured event trail
• a security requirement becomes a technical control
• a regulatory obligation becomes system evidence

That translation is where most of the real work happens, and it is engineering rather than policy work.

The agent needs a control plane

Which leads to the architectural conclusion. A serious agentic system is not an LLM with a prompt and API keys.

It needs a control plane around it: identity to establish who is acting, policy to define what is allowed, authorisation to decide whether this action is permitted now, tool control to limit which capability can be used, execution records of what actually happened, monitoring to judge whether behaviour is normal, audit to prove it, and defined points where autonomous execution stops.

The model remains important. But the model is no longer the architecture.

The control plane is what turns an AI capability into a system a business can rely on.

A Reference Architecture

A Reference Architecture

Assembled, the layers form a single path. Every request an agent makes travels through it in order.

USER → IDENTITY → AGENT → POLICY ENGINE → TOOL AUTHORIZATION → TOOL → BUSINESS SYSTEM → AUDIT AND MONITORING

What each layer contributes, in the order a request meets it:

Identity. Establishes the full attribution chain rather than collapsing it. When an investigation asks who authorised a change, the answer has to be more specific than "the assistant."

Agent. Reasons about the task and proposes an action. This is the only probabilistic component in the path, which is precisely why everything after it is deterministic.

Policy engine. Decides whether this action, by this identity, in this context, is permitted now. It sits between the agent and production because a prompt cannot enforce a rule.

The agent proposes. The system authorises.

Tool authorization. Resolves the decision to a specific named capability. Not database access, but getCustomerOrder, updateSupportTicket, createRefundRequest, approveRefund. Four named tools with distinct authorisation requirements are a different security posture from one connection string.

Business system. Executes. By this point the decision has already been made and checked, which is the entire purpose of the preceding layers.

Audit and monitoring. Records what happened and watches whether it should have. Built from the start, because evidence that was not captured cannot be reconstructed later.

Where human approval attaches

Approval that exists as a process step will eventually be skipped. Approval that exists as an execution token cannot be.

The agent prepares the action, the policy engine determines that approval is required, a human approves, a token is issued, and only then does the business system act. The difference is that the last step is technically impossible without the third.

Reversibility as a design constraint

Actions divide into reversible, recoverable and irreversible, and autonomy should be calibrated against that division rather than against confidence in the model.

Updating a ticket is reversible. Adjusting inventory is usually recoverable. Sending money, publishing a price to a live market, or emailing a customer base is not. The architecture should make the irreversible ones structurally harder to reach.

Explainability is not chain-of-thought

The model's reasoning text is not an audit record. A usable explanation covers the task, the relevant inputs, the selected tool, the authorisation, the policy decision, the action taken, the result and any human intervention.

That is a structured record of what happened, not a narrative of what the model was thinking.

Test against failure, not success

Most agent testing asks whether the agent completed the task. The more useful tests ask what happens when it should not.

Wrong information. Malicious information. Tool failure. Permission failure. Conflicting instructions. Context poisoning. Cascading failure. Human timeout.

An agent that has only been tested on success has not been tested.

Lifecycle and Maturity

Lifecycle and Maturity

Compliance work distributes across the development cycle rather than sitting at the end of it, because the decisions that matter most are cheap early and expensive to revisit. That pattern is not specific to AI, and we described it in The Hidden Cost of Choosing the Wrong Architecture.

Discovery establishes what the agent is for and what it may change. Architecture defines identity, authority and control boundaries. Development implements the tools and policy enforcement. Testing covers failure modes. Deployment establishes monitoring. Operation watches business outcomes rather than only technical ones. Review revisits whether the granted authority still matches the actual use.

A maturity model

Most organisations can locate themselves on a short scale.

• Level 0, experiment: prompt and model
• Level 1, assistant: model, interface, limited data access
• Level 2, integrated agent: agent with tools and APIs
• Level 3, controlled agent: policy engine, restricted tools, audit trail
• Level 4, governed system: the above plus monitoring, oversight, recovery and review

The gap between Level 2 and Level 3 is where most production incidents live, because Level 2 is genuinely useful and feels finished.

When you actually need this

Not every AI deployment requires the full apparatus described here, and treating them as though they do is its own kind of failure. The requirement scales with authority, not with the presence of AI.

An assistant that only generates content needs conventional AI governance. Accuracy, bias, disclosure. It cannot change anything, so there is nothing to authorise.

An assistant that retrieves private data needs identity, access control and data handling. It still cannot act, but it can now expose something it should not.

An agent that changes business state needs agentic controls: explicit authorisation, narrow tools, an audit trail. This is where most organisations arrive without noticing they have crossed a line.

An agent that executes high-impact or irreversible actions needs the full control plane, human oversight at defined points, and a recovery path.

The risk does not begin with the word AI. It begins with authority.

That distinction is worth applying honestly. A support assistant that reads order status and drafts replies does not need a policy engine. The same assistant, once it can issue the refund it just drafted, does.

Start with consequences, not compliance

The most practical way into this work is not to open a framework. It is to ask six questions in order.

What does the agent do? What can go wrong? What can the agent change? What would the consequence be? What control would prevent or limit that consequence? What evidence would prove the control worked?

Those six questions produce a more useful specification than most compliance checklists, because they start from the business rather than the regulation.

The New Software Boundary

The New Software Boundary

AI assistants are becoming part of the application rather than a feature attached to it, and that changes which questions matter.

The questions are not new. They are the ones software architecture has always asked: who can access the system, what can they do, which actions are permitted, how are they authenticated, how are changes recorded, what happens when something fails.

What is new is that the answer now includes a participant that reasons, and whose behaviour is probabilistic rather than deterministic. Where that participant sits in the wider commercial chain is the subject of SEO Gets You Found. AEO Gets You Recommended., and whether you need one at all is examined in Do I Need a Developer, or Is AI Enough?

Build the control layer before scaling the agent

The sequence that works: define the agent's responsibility, define its authority, design its tools, implement policy enforcement, create the audit layer, define human intervention, test failure modes, and only then connect production systems.

The sequence that does not work is the same list in reverse, which is how most agents reach production.

The question worth asking first

Not "which AI model should we use?" but:

What decisions and actions are we willing to delegate?

That question is answerable by a business without any technical knowledge, and everything downstream follows from it.

Where this ends up

The first generation of AI integration asked whether AI could be put into the product. The next asks whether AI can safely operate inside it.

When an agent can access data, choose tools, modify records, trigger workflows or execute transactions, compliance cannot live only in policy documents. It has to exist in identity, permissions, policy enforcement, tool boundaries, human oversight, monitoring, auditability and recovery.

The model provides intelligence. The agent provides autonomy. The architecture provides control.

AI agents will increasingly become part of websites, applications, e-commerce platforms and internal business systems. The question is not whether businesses will use them. It is how much authority they will give them.

Once software can act for a business, compliance becomes architecture.

Frequently Asked Questions

What is agentic AI compliance?

The practice of governing, securing, monitoring and auditing AI agents so their autonomous actions remain within applicable legal, organisational, security and operational boundaries. The distinguishing feature is that it addresses actions rather than outputs.

How is an AI agent different from a chatbot?

A chatbot generates responses. An agent can use tools, access systems, make decisions and execute actions. That difference creates requirements around authorisation, monitoring, auditability and human oversight that do not apply to a system which only produces text.

Does the EU AI Act regulate AI agents?

Yes, though not as a distinct category. The European Commission's AI Act Service Desk states that AI agents are not a separate category under the Act, and that the existing definitions of an AI system and a general-purpose AI model are sufficient to cover them. Obligations therefore depend on the system, its intended purpose and its risk classification. The Commission has also described its regulatory considerations on agents as preliminary at this stage.

When do the obligations apply?

The prohibitions on harmful manipulation and exploitation of vulnerabilities are already in force. Transparency rules apply from 2 August 2026 where an agent interacts with people or generates content. Additional requirements for high-risk systems apply from 2 December 2027 and 2 August 2028 respectively.

What are the biggest risks?

Excessive agency, excessive privilege, tool misuse, goal hijacking, identity and authorisation failures, memory and context poisoning, cascading failures, and human approval that has become a formality.

Should AI agents require human approval?

Not for every action. Oversight should be proportional to risk. Low-impact actions can be automated, while high-impact or irreversible actions may require approval or a prohibition on autonomous execution entirely.

What is least agency?

Limiting an agent's autonomous decision-making to what the task requires. It complements least privilege: least privilege constrains what the agent can access, least agency constrains what it can decide to do.

How do you audit an AI agent?

By designing an audit trail that records the initiating user, agent identity, task, tool, parameters, authorisation, policy decision, affected system, result and any human approval. Chain-of-thought output is not an audit trail.

When should this work start?

During architecture, before production. Adding controls to an autonomous system already in production is significantly harder, particularly where the original implementation did not capture the evidence needed for monitoring and audit.