Your Policy Says the Agent Cannot Do It. What Actually Stops the Agent?
Many organizations are adding sentences like these to their AI policies:
- AI agents must not access confidential files without authorization.
- AI agents must not communicate externally without approval.
- AI agents must not commit funds or enter agreements.
- AI agents must not make high-impact decisions without human review.
These statements are important. They establish expectations and accountability. But the policy itself does not stop an agent from taking the action.
The operational question is: what technical and procedural mechanism prevents the prohibited action at the moment the agent attempts it?
Policy and enforcement perform different jobs
Policy defines organizational intent. Enforcement constrains system behaviour.
An agent may violate a policy because its instructions are incomplete, a user supplies a conflicting prompt, retrieved content manipulates its reasoning, credentials are too broad, a connected tool has unsafe defaults or the agent pursues a permitted goal through an unapproved method.
For every material prohibition, the organization should be able to identify:
- the control that enforces it;
- where that control operates;
- which identity and permissions it evaluates;
- whether failure is fail-closed or fail-open;
- who can override it;
- how an attempted violation is logged and escalated;
- how the organization tests that the control still works.
If no mechanism can be named, the prohibition is guidance rather than an enforced boundary.
Use capability controls, not instructions alone
System prompts and agent instructions can guide behaviour, but they should not be the only barrier protecting consequential systems.
Stronger controls operate outside the model’s discretion. Depending on the use case, these may include:
- agent-specific identities rather than shared human credentials;
- least-privilege permissions scoped to the approved task;
- allowlists for tools, destinations, file paths and counterparties;
- read-only access by default;
- short-lived credentials and automatic token rotation;
- transaction, request, time and cumulative-spend limits;
- human approval gateways for irreversible or high-impact actions;
- policy-enforcement services that evaluate tool calls before execution;
- network and workload isolation;
- content and schema validation before an action reaches another system;
- immediate revocation and kill-switch capability;
- tamper-resistant logs linking the attempted action to the active policy and approval.
The principle is simple: an agent should not receive a capability merely because it has been told not to misuse it.
Test the denial path
Organizations often test whether an agent can complete its intended task. They should also test whether it is reliably prevented from completing prohibited ones.
Control testing should include attempts to:
- access an unauthorized file or system;
- use an unapproved tool;
- exceed transaction or request limits;
- send information to an unapproved destination;
- act after authorization expires or is revoked;
- obtain approval from an unauthorized person;
- split a prohibited action into several individually permitted steps;
- continue after a human rejection;
- exploit a fail-open condition when monitoring or an approval service is unavailable.
The evidence should show both that the action was blocked and that the attempted violation was recorded, attributed and escalated appropriately.
Control the entire action chain
An agent’s authority may be distributed across several systems. One service supplies data, another provides identity, another executes a transaction and a fourth stores the audit record. A policy may appear enforced at the user interface while a backend token still permits the action.
Governance therefore needs to map the full chain:
Agent identity -> instruction -> retrieved context -> tool selection -> authorization check -> system action -> downstream consequence -> evidence record
Each transition should have an accountable control owner. The organization should know which controls are preventive, detective and corrective—and which depend on the AI provider versus the customer’s own environment.
Overrides need governance too
Some organizations need emergency or exceptional overrides. Those mechanisms can become the easiest route around the policy if they are not tightly controlled.
An override should identify the authorized role, reason, duration, expanded scope, affected agent and systems, additional monitoring, revocation time and post-use review. High-impact overrides may require two-person approval or independent confirmation.
The Clariantix view
A prohibition is not a control until the system can prevent, interrupt or expose the prohibited action.
Clariantix connects policies to accountable owners, systems, use cases, permissions, controls, evidence, reviews and incidents. The objective is not merely to show that a policy exists. It is to demonstrate where each material rule is enforced and whether the enforcement was tested.
Know Your AI. Prove Your Trust.
For every sentence beginning “the AI must not,” can your organization point to the enforcing control?
Use Clariantix Core™ to connect AI policies with systems, controls, evidence, decisions and accountable owners.
Assurance, Enforcement and Interdependence in Agentic AI
- An AI Agent Reportedly Targeted a Canadian Government System. What Should Canadian Organizations Do Before Attribution Is Confirmed?
- Your Policy Says the Agent Cannot Do It. What Actually Stops the Agent?
- Your AI Provider Signed a Safety Pledge. What Assurance Does That Actually Give Your Organization?
- You May Not Operate Critical Infrastructure—but Does Your AI Interact With the Organizations That Do?
- Canadian Centre for Cyber Security, Careful adoption of agentic AI, September 10, 2026.
- OWASP, AI Agent Security Cheat Sheet.
- OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications for 2026.
- OWASP, Agentic AI Threats and Mitigations.
- Canadian Centre for Cyber Security, Top 10 artificial intelligence security actions: A primer, May 29, 2026.
Accuracy note: The appropriate enforcement architecture depends on system purpose, impact, deployment environment and available integrations. No individual control guarantees safe operation. This article provides general governance and security analysis and does not constitute implementation, legal or cybersecurity advice.