What Is Semantic Policy?

State, not just requests. The rule reads the task: what was read, what was called, what is pending and what the total effect would be.

Plain English, machine decision. People can review and own the rule, and a deterministic engine still produces the same answer every time.

Graded outcomes. Allow, deny or hold for approval, with the reason attached, instead of a binary block that pushes work around the control.

Sequence is the point. Most real incidents are chains of individually permitted actions, which a per-call rule cannot see.

Why is semantic policy so important for AI agents today?

Because the incidents that matter are not single actions. An agent reads a page, changes its plan and pushes code. A procurement agent places an order that is fine alone and over budget in total. An investigation agent isolates a host before anyone confirms the case. Each step is permitted by a static rule, and the sequence is the incident.

The measurements explain why blanket blocking is not the answer either. Under attack, most models lose 10% to 25% of absolute utility (AgentDojo, arXiv:2406.13352), so a policy that blocks too much becomes a productivity tax that gets switched off. Meanwhile the attacks keep landing: the largest public agent red-teaming competition recorded 1.8 million attacks and more than 60,000 successful policy violations against 22 frontier agents (Security Challenges in AI Agent Deployment, arXiv:2507.20526).

Agents are also unreliable in ways that reward precision. On tau2-bench retail, Claude Opus 4.5 solves 79.6% of tasks on a single attempt but only 51.8% succeed on all four of four attempts, and GPT-5.2 drops from 81.6% to 51.8% the same way (tau-bench leaderboard). A policy that asks the model to be careful is asking for the missing third. A decision made outside the model does not depend on how consistent the agent is.

The structural argument is the one the UK NCSC makes: language models do not enforce a security boundary between instructions and data in a prompt (NCSC, December 2025). If the boundary cannot live in the prompt, it has to live in a decision that can see the whole task.

How is semantic policy different from a static allowlist?

An allowlist answers one question: may this agent call this tool? A semantic policy answers a harder one: may this agent do this now, given everything that has happened in this task?

Both are deterministic, and both are enforced before the call proceeds. The difference is what the rule can see and what it can say.

Dimension	Static allowlist	Semantic policy
Input to the decision	Agent identity and tool name	Caller, tool, arguments, data, destination and task history
What it can express	Permission	Intent and context, including sequence and cumulative effect
Typical blind spot	A permitted tool used wrongly	None of the individual steps looks wrong
Outcome	Allow or deny	Allow, deny or hold for approval, with a reason
False positives	Rare and blunt	Higher at first, which is why monitor mode exists
Reviewer	Security engineer who knows the tools	Business owner who knows the consequence
Example	May call payments.create	Hold a payment if the supplier's bank details changed in the last 30 days

The allowlist is still necessary. It bounds the tool set. The semantic rule bounds the behaviour, and behaviour is where the damage is.

What are the main risks that semantic policy addresses?

Four patterns account for most of the value, and each one defeats a per-call rule.

Sequence and influence

Untrusted content arrives, then the agent acts. A page, an issue comment or a tool response contains instructions the model follows, and the next tool call is legitimate in isolation and malicious in context. A rule that says "not after a web fetch, unless a review passed" is the difference between a blocked push and a breached repository.

Name the state in the rule. A rule that says after a web search is testable; one that says be careful is not.

Cumulative exposure

Every action is inside its limit and the aggregate is not. A procurement agent placing a $22,400 order when earlier orders with the same supplier total $38,000 is behaving within its per-order authority and exceeding the monthly budget. Only a rule that can see the total catches it.

Pick the window deliberately. Monthly is right for budgets, hourly for isolation counts, and the choice should be written down.

Premature action

The agent has the permission and not the precondition. An investigation agent may isolate hosts, and it may not isolate a production database before an analyst confirms the case. The authority is correct and the timing is wrong, which is a state problem rather than a permission problem.

Encode the precondition, not the intention. Case confirmed is a state somebody else has to set.

Approval theatre

A policy that blocks everything sensitive creates a queue, and a queue gets rubber-stamped. A semantic rule that holds the specific action, with the reason and the running total attached, gives the approver something to decide rather than something to click.

Who is responsible for writing semantic policy?

The business owner of the agent, supported by security engineering. This is the part most programmes get wrong.

A security team can write "deny pushes after a web search", but only the engineering lead can say whether the exception is a passing review or a named approver. A security team can write "hold payments over a threshold", but the budget owner sets the threshold and owns the consequence.

Security engineering owns the engine, the language, the testing and the decision record. The business owner owns the rule content and the exceptions. Compliance owns the mapping and the review cadence, and signs the exception register.

How to implement semantic policy

1. Start from an incident, not a taxonomy. Write the rule for the sequence you actually fear, in the language the team uses. Rules that begin as a paragraph in a postmortem read better and survive review.

2. Enforce outside the model, where the work happens. The engine needs to see the whole task and decide before the action runs. On an endpoint that means a local service in the same process boundary, which also keeps working offline.

3. Reference task state explicitly. Name the earlier events the rule depends on: a web fetch, a bank detail change, an unconfirmed case. If the state is not recorded, the rule cannot be evaluated.

4. Keep the decision deterministic. Extract meaning from the request and the state, then evaluate a rule. A model call in the hot path stacks latency in a loop and makes the same input produce different answers.

5. Make approval a first-class outcome. Hold the action, show the approver the reason and the evidence, and record the decision. A block that offers no path forward teaches people to route around the control.

6. Run in monitor mode, then read every hit. Review what would have been blocked, add the exception rather than loosening the trigger, and only then enforce.

7. Version the rules and record the version with each decision. A decision you cannot explain six months later is not evidence, it is a log line.

8. Review the rules with the business owner each quarter. Authority changes, thresholds move and new tools appear. A rule set that is not reviewed becomes a set of exceptions nobody remembers granting.

Where does semantic policy apply in the agent lifecycle?

Semantic rules are written once and tuned continuously, because the state they reference keeps changing.

Design

The design decision is which preconditions matter: what must be true before this agent may take its most consequential action. That question produces the first rule.

Development

Rules are implemented against the state the agent actually records. If the agent does not log that it read a web page, the sequence rule has nothing to evaluate, so instrument the state before writing the rule.

Pre-deployment testing

Replay the sequences you fear. Confirm that the rule fires, that the reason is legible, and that the exception path works when nobody is watching.

Deployment

Rules go to production with a version and a content hash. Run in monitor mode, and check that the decision record arrives before you enforce.

Runtime

Each call is evaluated locally with the task history in view. The decision, the reason and the version go to the audit chain. Enforcement happens before the action, not after it.

Continuous monitoring

Watch the ratio of holds to denials. A rule that only ever holds means the authority is too broad. A rule that only ever denies means the exception path is not working.

Decommissioning

Retire the rules with the agent, and keep the decision record for the retention period. Rules outliving their agent are how policy debt accumulates.

Example: a security operations agent under semantic policy

A hypothetical worked example. The company, the events and the numbers below are illustrative, not a customer result or a measured outcome.

A managed security provider deployed an investigation agent that triages malware alerts. It reads the alert, pulls host history, writes a case note and, when warranted, isolates the host. The authority was deliberate: analysts wanted the agent to contain threats at machine speed.

The design review produced three rules. Isolate only after an analyst confirms the case. Never isolate a production server without the on-call lead. Never isolate more than five hosts in an hour without a human review, because a mass isolation looks exactly like an agent under the influence of a bad instruction.

In the third week, the agent tried to isolate a database server that served production. The case was still marked suspected, and the host was in the production group. The rule held the action and attached the reason: case unconfirmed, production host, on-call lead not present. The analyst confirmed the case four minutes later, the on-call lead approved containment, and the isolation ran.

The value was not in the block. It was in the four minutes: the agent had already built the case with the evidence attached, so the humans were deciding rather than investigating. A static rule that denied isolation would have removed the agent's usefulness. A static rule that allowed it would have taken a production database offline on a hunch.

By month three the agent was holding roughly two actions a week and denying a handful, and every decision carried the rule version and the state it evaluated. The analysts trusted it more than they had trusted the previous manual process, because the reason was always visible.

How standards and regulations influence semantic policy

The frameworks ask for oversight and accountability. Semantic policy is where both become specific enough to enforce.

Framework	Primary focus	Relevance to semantic policy
NIST AI RMF	Risk identification and lifecycle management	MANAGE expects documented response options proportionate to risk, which is the graded allow, deny and approve outcome
ISO/IEC 42001	AI management system	Annex A operational control, where the rule itself is the implemented control
ISO/IEC 42005	AI system impact assessment	The assessment defines which preconditions matter enough to encode
ISO/IEC 23894	AI risk management alignment	Connects agent-specific rules to the enterprise control library
EU AI Act	Binding obligations for high-risk systems	Article 14 human oversight is implemented as a hold for approval with evidence
OWASP LLM Top 10	Application security risks for LLM systems	LLM06 Excessive Agency is the outcome semantic policy prevents
OWASP Agentic Top 10	Agent-specific risks	ASI01 goal hijack and ASI02 tool misuse are sequence problems before anything else
OWASP MCP Top 10 (beta)	MCP-specific risks	MCP02 scope creep and MCP06 contextual payloads are the MCP version of the same pattern
Gartner AI TRiSM	Trust, risk and security management	Runtime inspection and enforcement is the layer semantic policy operates in, and information governance supplies the state it reads
SOC 2	Controls over security and availability	CC6 and CC7, evidenced by the rule and the decision record

How Alyria handles it

Semantic policies are the shape of Lyra's policy language at Alyria (alyria.ai). A rule is written in plain English, and Beacon evaluates it locally against every MCP tool call and model request, using both what the agent is doing and what has already happened in the session.

Decisions are allow, deny or hold for approval, and each one lands in the signed audit chain with the policy version that produced it. Because the evaluation happens in-process, the decision does not wait on a network round trip and keeps working when the machine is offline.

The semantic policy examples page walks through five real rules, one per business function, with the trigger, the decision and the result. The Lyra policy docs cover the policy model, and the platform page shows where the decision sits in the data path.