Why agents need an enforcement layer — and why it has to be runtime.

For thirty years, the trust boundary of an application sat at the keyboard. A human typed; the system did. Review was implicit in that gap — small, but real.

Models with tools removed the gap. The agent reads, decides, and calls — the same loop, with no person between the intent and the action. A user typing DELETE FROM users is rare and is reviewed. An agent constructing it is common and is not.

The boundary did not disappear. It moved inside the process — somewhere between the model’s output and the tool’s effect — and almost no one is guarding that line.

Most of what gets called “agent safety” today is detection: an audit log, an evaluation suite, a red-team report. All of it useful. None of it sufficient.

By the time the log is written, the email is sent, the row is deleted, the wire is transferred. The audit becomes a record of what already cost you something.

An audit without enforcement is a confession, not a control.

Detection is necessary — the same way an IDS is necessary — but no one ships a network with only an IDS and no firewall. Agents deserve the same treatment.

A natural-language instruction inside a prompt is not a control surface. It’s an intention, expressed in the same medium an attacker uses against you.

“Ignore previous instructions” isn’t a clever exploit; it’s the natural conclusion of letting prose do the work of a permission system. The fix isn’t a better prompt — it’s a different layer.

Policy must live where it can be read by people who don’t write the agent — security, legal, the on-call engineer at 3 a.m. — and that means code. Version-controlled, reviewable, replayable.

# Policy is code. Review it like code.
- match: { tool: "db.query", op: "DELETE" }
  decision: block
  reason:   "writes outside support-bot scope"

- match: { tool: "http.fetch", host: "*.internal" }
  decision: allow

YAML and Rego are not glamorous. They are also not negotiable.

The model is the wrong place to enforce. So is the user, the framework, and — especially — the prompt. The only place left is the runtime: the layer between the agent’s decision and the system that carries it out.

A runtime gate has properties prompts and models do not have:

• →It is deterministic. Same input, same decision.
• →It is auditable. Every allow and every block recorded.
• →It cannot be argued with by a long enough message.

It is also boring. We think this is a feature. Boring infrastructure is what carries weight you cannot afford to lose. TLS, sudo, IAM — none were exciting. All are loadbearing.

Lictorate is a company whose entire purpose is the runtime described in §04. We start with one product, narrowly, on purpose.

AgentGuard. An open-source firewall for AI agents. You wrap the tool layer, you write a policy, the gate decides. Self-hosted by default; we never see the traffic.

If the model is wrong, if the prompt is hijacked, if the framework is updated badly — the policy still holds. That is the entire bet.

The core stays open. Forever. The hosted control plane on top — for teams who want a UI, audit export, and a SOC-friendly story — is how we plan to make a living. The runtime is the company; the platform is the business model.

• →Not an alignment lab. The model can be as well-aligned as it likes; we still want a permission check between it and your database.
• →Not a prompt-injection detector. Detection is §02. We are interested in the line that holds after detection failed.
• →Not an agent framework, an LLM gateway, or an observability product. The category we are building is upstream of all three.
• →Not, at this stage, large. Mail goes to a person. Pull requests are read. We are deliberately small.