The AI Security Controller

Most enterprise AI deployments fail their first security review for the same reason: the model is given a set of tools and a set of credentials, and nothing sits between the two. The agent decides, and the system executes. There is no point in that path where an organisation can say this action was permitted, by this policy, on behalf of this person, and here is the record.

This paper describes the component that belongs in that gap. We call it the AI Security Controller: a policy enforcement point that sits between the model plane and the systems of record, and which every agent action must pass through.

It is a reference architecture, not a product. The components below are boundaries and responsibilities — implement them in whatever stack you already run.

Why a controller, and not guardrails

The prevailing pattern is to defend at the model: system prompts that describe forbidden behaviour, output filters that scan for policy violations, evaluation suites that measure refusal rates. This work matters, but it is defence at the wrong layer for anything that writes.

Prompt-level controls share one property — they are advisory. They express intent to a probabilistic system and measure how often that intent is honoured. A control that holds 99.4% of the time is not a control an auditor will accept on a payment initiation path.

The controller inverts this. Instead of asking the model to behave, it makes misbehaviour unrepresentable: the agent cannot call what it has not been granted, cannot write what policy forbids, and cannot act at all without leaving a record. The model becomes an untrusted input to a trusted system rather than a trusted actor in an untrusted one.

This is a familiar move. We do not secure databases by asking applications to write only correct queries; we grant scoped credentials and enforce constraints at the boundary. AI agents deserve the same treatment, and for the same reason.

Trust zones

The architecture divides the system into four zones. Data crosses zone boundaries only through defined interfaces, and trust never flows outward.

┌─ Zone 0 ── UNTRUSTED ────────────────────────────────────┐
│  User prompts · retrieved documents · tool results       │
│  web content · uploaded files · prior conversation       │
└────────────────────────┬─────────────────────────────────┘
                         │  all treated as hostile input
┌─ Zone 1 ── MODEL PLANE ▼─────────────────────────────────┐
│  Inference · reasoning · tool selection                  │
│  Produces INTENT, never EFFECT                           │
└────────────────────────┬─────────────────────────────────┘
                         │  proposed action + arguments
┌─ Zone 2 ── CONTROLLER ─▼─────────────────────────────────┐
│  Identity · capability scope · policy · checkpoints      │
│  Provenance · egress control · reversibility             │
│  ── THE TRUST BOUNDARY ──                                │
└────────────────────────┬─────────────────────────────────┘
                         │  authorised, attributed call
┌─ Zone 3 ── SYSTEMS OF RECORD ▼───────────────────────────┐
│  Core banking · LMS · CRM · ERP · document stores        │
└──────────────────────────────────────────────────────────┘

The critical property is at the Zone 1 / Zone 2 boundary: the model plane produces intent, never effect. A model emits a proposal — call transfer_funds with these arguments — and that proposal is data. It becomes an action only when the controller authorises it.

This distinction is what makes prompt injection survivable. An injected instruction hidden in a retrieved document can change what the model proposes. It cannot change what the controller permits, because the controller's policy is not in the context window.

The seven control points

Every action crossing Zone 2 passes through the same sequence. The order matters: each step assumes the previous one has succeeded.

1. Identity and attribution

Every agent action resolves to a human principal. Not a service account, not "the assistant" — a named person who holds the authority the action consumes.

Where an agent runs unattended, it acts under a delegated authority with an explicit grant: who delegated, what scope, until when. Delegation is a first-class record, not an implicit property of a long-lived key.

The test: for any action in the log, you can answer whose authority was this? without inference.

2. Capability scoping

The agent is granted a set of capabilities, not a set of credentials. A capability is a named operation with a declared shape — read_customer_profile, draft_payment_instruction, submit_payment_instruction — bound to the principal's own permissions.

Two rules make this work:

Enumerate, never inherit. An agent working on behalf of an administrator does not receive administrator scope. It receives the specific capabilities the task requires.
Split read from write, and draft from submit. The most useful boundary in practice is between preparing an action and committing it. Most agent value is in the preparation.

Capabilities are resolved before the model sees its tool list. A capability the principal lacks is not presented as an unavailable tool — it is absent, and the model never proposes it.

3. Policy evaluation

The proposed call, its arguments and the resolved principal are evaluated against policy before execution. This is the controller's core, and it should be deterministic code, not a model.

Policy answers questions the model cannot be trusted to answer about itself:

Is this capability permitted for this principal, in this context, at this time?
Do the arguments fall within bounds — amount thresholds, counterparty allow-lists, record ownership?
Does this action, combined with what this agent has already done this session, exceed a rate or aggregate limit?

That last question is the one most implementations miss. Individual actions are frequently benign while a sequence is not: fifty individually-permitted record reads are an export. Policy needs session state, not just request state.

Fail closed. An unevaluable policy denies. A controller that permits when uncertain is a controller that permits under attack.

4. Human checkpoints

Some actions must not execute on a model's judgement alone, however good the policy. The line is not "important" — it is reversibility.

Classification	Property	Handling
Reversible	Undo restores prior state	Execute, log
Compensable	Effect can be offset, not erased	Execute, log, notify
Irreversible	No path back	Human approval, always

Money leaving the institution, communication reaching a customer, deletion of records under retention, and any change to the controller's own policy are irreversible. They get a checkpoint.

The checkpoint must present the resolved action, not the model's description of it. Show the actual call, the actual arguments, the actual counterparty — not a natural-language summary the model wrote. An agent that can word its own approval request can talk its way through the checkpoint.

5. Provenance capture

For every action the controller records, as a single linked unit:

The principal and any delegation chain
The model, version and configuration that produced the intent
The inputs that were in context — retrieved documents, tool results, prior turns
The proposed call and its arguments
The policy decision and the rule that produced it
The execution result
Any human checkpoint and who cleared it

The context record is the part usually skipped, and the part an incident investigation needs most. When an agent does something inexplicable, the answer is almost always in what it was shown. Without that, you have a log that tells you what happened and never why.

This record is written before execution and completed after. A crash mid-action leaves evidence, not silence.

6. Egress control

The controller governs what leaves, not just what executes. Every outbound payload — an API call, an email, a file write, a model request — passes an egress check.

Two questions:

Classification. Does this payload contain data of a class this destination may receive? Customer identifiers to an external model endpoint. Payment detail to a logging service. Health information crossing a jurisdiction.
Residency. Where does this destination physically process and store? For Australian government, health and education work this is frequently the binding constraint, and it is a property of the deployment rather than the code.

The model plane is itself a destination. A hosted model endpoint is an external system that receives everything in the context window, and egress control applies to it exactly as it applies to any third party. This is the single decision that most often determines whether a design is viable in a regulated environment — and the reason our own developer tooling runs local-first with no telemetry: the cheapest egress control is not having an egress.

7. Reversibility

For every capability classified as reversible or compensable, the controller holds the compensating action — and holds it before the original executes.

This is not a database transaction. Agent actions span systems that share no transaction manager: a CRM write, an email, a file move. Reversibility here means each capability declares how to undo itself, and the controller records enough state to invoke that path.

The operational requirement this serves is narrow and important: when an agent behaves incorrectly, you need to bound the damage in minutes, not reconstruct it from logs over days. A session-level rollback — reverse every reversible action this agent took in this session, in order — is the control that makes an incident recoverable.

Where the controller sits

   Human ──▶ Agent runtime ──▶ ┌──────────────┐ ──▶ Systems
                               │  CONTROLLER  │
   Policy store ──────────────▶│              │◀── Identity provider
   Capability registry ───────▶│              │
                               └──────┬───────┘
                                      ▼
                              Provenance store
                              (append-only)

Three implementation properties matter more than the internals:

The controller is in the data path, not beside it. An observability tool that watches actions and alerts is not a controller. If it cannot deny, it is not enforcing.

The provenance store is append-only and separately controlled. If the agent's own credentials can modify the audit record, there is no audit record. In practice this means a different store, different credentials, and retention that outlives the agent.

Policy is versioned and deployable independently. You will change policy in response to incidents, and you will need to answer which policy was in force on a given date. Treat it as code: reviewed, versioned, and referenced by version in every decision record.

What this does not solve

A reference architecture that claims completeness should be distrusted. This one has clear limits:

It does not make the model correct. A well-controlled agent can still propose bad-but-permitted actions. Evaluation, prompt design and model choice remain necessary; the controller bounds the blast radius rather than improving judgement.
It does not prevent prompt injection. It contains it. An injected instruction still changes what the model proposes — the controller ensures the proposal is evaluated on its merits rather than its persuasiveness.
It adds latency. Policy evaluation, provenance writes and checkpoints cost time. For a conversational assistant this is usually immaterial; for high-frequency automated paths it needs designing for.
It cannot fix an over-broad capability. If update_customer permits changing a payment destination, no amount of logging makes that safe. Capability design is the highest-leverage work in this architecture, and the least automatable.

Implementation sequence

Organisations that succeed with this generally build it in this order. Each phase is independently useful, which matters — a two-year controller programme with no interim value does not survive its first budget review.

Phase 1 — Observe. Route agent actions through a pass-through controller that records provenance and denies nothing. You learn what your agents actually do, and you have an audit trail from day one. Usually weeks.

Phase 2 — Scope. Introduce the capability registry. Replace inherited credentials with enumerated capabilities. This is where most latent risk is removed, and it typically surfaces at least one agent holding far more authority than anyone believed.

Phase 3 — Enforce. Turn on policy evaluation, starting in report-only mode and comparing what would have been denied against what actually happened. Promote to enforcing once the delta is understood.

Phase 4 — Checkpoint. Classify capabilities by reversibility and add human approval on the irreversible set. Deliberately last, because it is the step that changes user experience, and it lands better once the preceding phases have established what agents genuinely need to do.

Review checklist

For assessing an existing deployment:

Every agent action resolves to a named human principal
Agents hold enumerated capabilities, not inherited credentials
Read and write capabilities are separately granted
Draft and submit are separate capabilities on any irreversible path
Policy is deterministic code, evaluated outside the model
Policy has access to session state, not only the current request
Unevaluable policy denies
Irreversible actions require human approval
Checkpoints display resolved calls, not model-written summaries
Provenance includes the context the model was shown
The provenance store cannot be written by agent credentials
Egress classification covers the model endpoint itself
Data residency is verified for every destination, including inference
Reversible capabilities declare a compensating action
Session-level rollback exists and has been tested

Fewer than ten of these is normal for a first deployment. All fifteen is the bar for anything touching money, health records or student outcomes.

NexomCore builds AI platforms and enterprise systems for regulated Australian organisations. If you are designing an agent deployment and want a second opinion on the control surface, we are happy to look at it.