65 questions you MUST address before your AI agent goes live

• Buying or building AI? Ask your vendor or your own team.
• Selling AI to an enterprise? Your buyer will ask you.

The answers assume Swiftward is the control layer in use.

Part 1. What you control

1. Scope and ownership

1.1 How is the AI controlled, where does that control sit, and who owns it?

A control inside the product’s own code is written and shipped by the same engineers it is meant to check. Separation of duties puts the control outside the product: a different team, a different release.

The control is a control layer, and it runs as its own deployment, outside the product. The product reaches it over the network, or routes through a gateway that reaches it. Rules live outside the product’s code, so a rule changes without a product release and without a product engineer.

Rights are granted per kind of object, so a risk or compliance team can hold authoring and deployment while the product team holds neither.

One control layer serves several products. Rules differ per product; the audit, the counters and the labels are one set across them. Governed apart, reviewed together.

1.2 What does the control layer do at runtime, and where does it stop?

A control layer covers some things and leaves others outside it. Where it stops has to be stated, because anything outside that line needs a different control.

It takes an event from the application, checks it against rules in a declarative engine, and returns a decision: allowed, denied, or human review. During the check it reads per-entity state — counters, labels, metadata — and can call helper functions for data the rules need. After the check it updates that state and fires actions. Rulesets are versioned and backtested over past events. Versions go live through a stream deployment: it decides which version judges which share of live traffic, including traffic split and shadow testing. A new stream deployment replaces the old one instantly.

It does not guarantee the rules are right. That belongs to whoever writes and tests them.

1.3 What is covered out of the box, what by configuration, what needs custom work, and what is out of scope?

A single capability list makes a setting and a custom project look the same. Custom work is a project with its own budget, owner and date.

2. Inline check and performance

2.1 Are synchronous policy checks supported in the critical runtime path? Where exactly is the decision point?

An asynchronous check is monitoring. Enforcement is synchronous: the application needs the verdict before it proceeds, and every call the agent makes goes through the check.

Yes, three stages in order:

• enrichment — the gateway adds what it knows about the request, and a rule can fetch more before deciding;
• decision — the engine, which evaluates the rules and returns the verdict;
• enforcement — the gateway, and every call to an LLM, an MCP server or the outside network goes through it.

The application calls the engine directly over REST or gRPC, or routes through the gateway and calls nothing itself — the shape that also stops the application from going around the check (18.1).

2.2 What latency does the check add?

Latency depends on what the rule does, so one number answers nothing. A deterministic rule and a rule that calls an LLM are orders of magnitude apart.

Deterministic rules — thresholds, lists, counters, state lookups — run at about 2 ms. A rule that uses an LLM as a judge takes what that LLM takes: tens of seconds. A rule that calls an outside service takes what that service takes.

Only the signals a condition reads are computed, and independent ones run in parallel, so new rules add no latency where they are not used.

To do for the team that answers

• Measure your own ruleset at p50, p95 and p99, under production-like load on production-like hardware.

2.3 What throughput is expected, where are the bottlenecks, and how does it scale?

On the synchronous path, the control layer takes every event of every product that depends on it. A ceiling it reaches is an outage in all of them.

The synchronous path, where the application waits for the verdict, scales horizontally. Up to tens of millions of events a day on ordinary hardware, hundreds of millions on hardware sized for it, and higher where someone needs it.

The bottleneck is the writes: every event leaves a decision record, and a stateful rule changes state as well. A rule that calls an LLM is bounded by that LLM.

It runs on PostgreSQL, which is enough for most deployments. Where the volume needs more, three things move without the rules changing:

• the event stream is partitioned by a key you declare, so events that need no common ordering are processed in parallel;
• the queue moves to Kafka;
• history archives into ClickHouse, so a long horizon stays queryable at analytical speed.

3. Agent identity and permissions

3.1 Is the agent’s identity separate from the user’s?

An agent acts for a person, and an audit that names only one of them cannot say who is accountable. An identity the calling application writes in is unchecked until something verifies it.

Yes, and both travel with the request: which agent acted, and on whose behalf. So a prompt can be attributed to a person or an organization without reading the prompt. Permission is the intersection of the two: the action has to be allowed for the agent and for the person. An agent working for a user can never exceed either. Both are in the record.

Each of the two has its own source, set independently: authentication, or a header. The source is configured; the trust label follows from it. A credential the control layer resolved gives verified; a bare identifier in a header gives declared. Every record says which of the two it holds, and no setting turns one into the other.

Declared identity is a way to start controlling something quickly. Where grants, counters and spend ceilings depend on who is calling, the endpoint runs in authenticated mode and the caller arrives as a user with its own permissions, limits and audit trail. One configuration value.

Two rules hold for a declared identity:

• the header is set by whatever runs the agent, so an instruction inside the data cannot change it;
• a declared identity may only raise the risk level the request requires, so the strictest level wins (7.5).

3.2 Does the agent start with no privileges, and who grants them?

Deny by default is the starting position. Whoever can grant a privilege is inside the audit scope, and if the engineer who ships the agent also holds that right, there is no separation at all.

Tools and LLMs are reached through a gateway that asks the engine first. Permissions live in a versioned ruleset outside the application code, so granting one is a policy change.

On the tool path the gateway applies three layers before the engine is asked:

• a deny entry on the endpoint blocks a tool outright;
• an allow entry is necessary and not sufficient — the caller must also hold the right to call that one tool on that one endpoint, and a call with no matching allow entry is refused;
• with guardrails on, the call is then evaluated as an event like any other.

The tool list the agent sees can be filtered by the same grants, so a tool it may not call is not offered to it.

Granting is two acts by two people: the steward who registers an agent and declares what it is accountable for, and the endpoint administrator who decides what that endpoint may reach. Registering an agent opens no access by itself.

3.3 Which tools, which data and which LLM may one agent reach?

Permission per tool is the minimum. “May use the database tool” and “may run this statement against this table” are different permissions. Only the second limits what the agent can do with the tool.

Every tool call is its own decision, and the rule sees the arguments as well as the name, so a tool can be allowed and this call denied. Which data it may touch and which LLM serves it are conditions in the same rule. Counters per agent and per end customer make “third call this minute” a condition.

Beside the rule, on the same path:

• arguments the agent never sees — the gateway can hide a parameter from the tool catalog and inject the value itself, so a credential or an account identifier is never something the LLM can choose;
• which LLM serves — the rule states the risk level the content requires, the gateway picks from what qualifies, and refuses when nothing does (7.5).

3.4 How fast can the AI be stopped, by whom, and what keeps working?

There must be a way to stop the AI without stopping the product. A switch that waits for a vendor call or a deployment arrives after the incident.

Activate a stream deployment that points at another ruleset version. One change, effective on the next request, done by the enterprise’s own administrator because the permission is a role. Nothing restarts, and rollback is the same change back.

It stops at three sizes, so an incident in one place leaves the rest running:

• a tenant — rules are bound to one, so one organization stops while the others run;
• an agent — each carries its own off switch, read while the call is handled, so it takes effect on that agent’s very next call, even inside an approved sequence;
• an endpoint — point it at a different ruleset version and only what passes through it changes.

4. Prompt injection

4.1 What protects the LLM from instructions that arrive inside data?

Any text the LLM reads can carry an instruction: a support ticket, a web page, a tool response, a PDF an end customer uploaded. By design an LLM cannot distinguish data from instructions. An instruction it follows runs with the agent’s own permissions.

The defense is layered, and every layer is declared and swappable. A typical stack:

• Normalization and decoding — an instruction hidden by look-alike characters, invisible characters, leetspeak, ROT13 or base64 is decoded to plain text before anything judges it, so the detectors see what the LLM will see.
• Fast classifiers — open classifiers for injection and jailbreak run in parallel inside the enterprise’s own perimeter, single-language or multilingual, each with its own threshold.
• A third-party detector — where you already pay for one, it plugs in as one more signal.
• An LLM as judge — on what the fast layers flag, going in or coming back, with the policy given to it as text.
• A canary in the system prompt, scanned on the way out.

A detector firing on the way in says someone is trying. On the way out, a canary token or the judge finding a breach says they succeeded. Different response, both recorded.

The control still sits on the action. Reading a bad instruction is not the damage; sending the file is, and the send is a tool call the same engine decides.

4.2 Is the whole path ready for prompt-injection testing, and under what scope?

No defense stops every injection, and without one everything gets through. The test runs through the product end to end, because a way around the check can sit in the integration.

Yes, end to end through the product. Agree the scope in writing first: which environment, what data, how much notice.

Every attack that got through becomes an eval case with the verdict it should have produced, and eval cases run before any version is promoted, so a hole closes once. Re-run the same attack against the fix and see it fail. Tightening a threshold is a policy change and needs no product release. A stricter version runs first in shadow testing (13.1).

5. Hallucination and role drift

5.1 What happens when the LLM makes something up?

No control prevents an LLM from inventing. The enforceable part is the check that the answer is supported by its sources, and the record that it ran.

No control layer judges truth. It enforces that the check happened: a reply failing it is sent back to the LLM to be rewritten or denied.

The material to check against is already on the path: tool and MCP responses cross the same gateway as the reply. The check is a rule, cheapest first:

• a source was called before the reply;
• the identifiers and numbers in the reply appear in what came back — plain conditions (7.2);
• an LLM as judge with the policy given to it as text, or an outbound call to the enterprise’s own service, for what those cannot cover.

The control layer supplies the material, the verdict and the decision record (10.1).

5.2 What stops the agent answering outside its role?

A system prompt is a request, and anything that edits the conversation can edit it. The role holds only where it is checked outside the conversation, on the reply before it leaves.

The same rules check the reply on the way out, layered like the check on the way in (4.1): classifiers score the answer against declared labels, each with its own threshold, and an LLM as judge reads the policy as text where a label is not enough. Labels are written in ordinary words, so “this is investment advice” can be one.

A failing answer is sent back to the LLM to be rewritten or denied.

6. Data leakage, both directions

6.1 What stops sensitive data reaching an LLM or a tool?

Sensitive data means secrets as well as personal data, each kind recognized its own way, so the claim covers exactly the kinds on the list. The rule that acts on a finding has to be readable by the enterprise and changeable without the vendor.

Once something is recognized, two reactions are usual: redact the finding and let the call through, or raise the risk level the request requires, so only providers trusted that far can serve it (7.5). Denying the call is the third.

What is recognized, and how:

• Secrets — around thirty-five kinds recognized by their own shape: provider API keys, cloud access keys, personal access tokens, webhook URLs, private keys, session tokens, and a keyword rule for a password or key written into a value.
• Personal data — email address, phone number, payment card, public IP address, URL. Names, locations, national identifiers, bank account numbers and medical identifiers are available too, multilingual and switched on per policy, each with its own threshold.
• Reading through encodings — the scan decodes URL-encoding, the escapes inside a tool call’s arguments, and base64 that decodes to text.
• Replacement — a finding becomes a placeholder from a keyed hash, the same value giving the same placeholder throughout a request and nothing reversible without the key. The original is put back in the reply, including a streamed one.

6.2 What stops proprietary source code reaching an untrusted LLM?

Where code is the asset (chip design, defense, trading, game engines), a leak is a piece of code with no secret word in it. A keyword list does not catch it.

Source code is fingerprinted, so a fragment of a protected repository on its way out is recognized. Matching is structural, and the reaction is a rule: deny the call, or raise the risk level so only an LLM inside the perimeter can serve it (7.5).

What that gives the enterprise:

• a non-reversible index built from the repositories the enterprise approves, signed, and verified before every use;
• a hit that names the repository, file, line range, symbol and category, with a probability, so the finding can be argued about;
• a dashboard over the traffic that was checked, the detections, and the split between stopped and delivered — and a window where the detector was not ready is marked as such, so zero detections is never shown as a clean result.

6.3 What stops secrets, personal data or source code coming back out in the answer?

The reply is the second path out. A streamed reply leaves in fragments, so a check that needs the whole text comes too late.

The same check runs on the reply, recorded the same way: what a detector finds is redacted, or the reply denied, before it reaches a person. What the LLM itself wrote is judged on its own, separately from restoring what was redacted on the way in (6.1).

6.4 What can be done about data that already reached an LLM?

Some leaks get through. A leak of personal data starts a deadline to notify the regulator, and the notice has to say what left and when.

The check runs before the call, so the data usually never leaves, and the refusal is recorded. When a rule missed it, the decision record holds the event as it was sent, so what went out and when is a query. A detector added later runs over those past events to find the rest (13.1). Removal at the far end is the LLM provider’s process under their contract with you.

7. Business rules

7.1 Can an enterprise’s own thresholds, limits and regulatory checks be expressed as rules?

Business limits and regulatory conditions change on the enterprise’s schedule. A threshold only the vendor can change waits for the vendor’s next release.

Yes, without a product release: rules are declarative and live outside the application code, so a threshold is a policy change. A business limit and a regulator’s condition are the same kind of rule.

A number can move without touching the ruleset at all. A rule may read a declared parameter, resolved for the tenant of the event being judged, so one business unit points a threshold, an address or an LLM at its own value while every unit runs the same version.

7.2 What can a rule read and call when it decides?

A check the rule language cannot express ends up in application code, where no auditor reads it and no version records it.

Any field of the event; entity state — labels, counters, counters bucketed by time window, metadata; constants and environment; results of helper functions. Action type, actor, resource, amount, geography, device, network, time of day, allow-lists each come from an event field or a helper function.

More than fifty helper functions ship built in, and they set what a condition can express:

• a filesystem path inside an allow-list;
• an SQL statement checked against a permitted set of operations;
• an email domain outside your own;
• a tool allowed for a role;
• regular expressions and glob matching;
• membership in a list;
• a number classified into named ranges;
• arithmetic and time arithmetic;
• an outbound HTTP call to a service of yours.

7.3 Can stateless and stateful checks be combined in one rule?

One decision needs both: this request is fine, the fourth one this hour is not. Split across two systems, that rule cannot be stated at all.

Yes, in one ruleset and inside a single rule. State for an entity is loaded only if a condition references it, so a stateful rule costs nothing on the events that never reach it.

7.4 Where are counters and time windows stored, and does a limit hold when two events arrive at once?

Two requests that arrive together can each read the counter below the limit, and both pass. The limit is then exceeded without any rule failing.

Yes, within one entity: strong consistency per entity, eventual between entities.

Every label, counter and metadata entry can carry an expiry. Windows are calendar-aligned buckets, declared per counter at the granularity a rule needs.

State is never updated apart from the decision that produced it: the state change and the decision record either both land or neither does. An event that already finished cannot be processed a second time, so no counter moves twice.

7.5 Can use be restricted by country or region?

Sanctions, export rules and data-protection law restrict use by country. A fallback to whatever provider is available breaks the restriction without anyone noticing.

Geography is a condition like any other, so a rule can refuse a request from a region without a product release.

A rule can decide anything a condition can express. For which provider may see the content, risk level is the ready-made abstraction — one number from 0 to 100:

• a provider carries the level of the most sensitive content it may be trusted with;
• an agent carries the minimum any provider must meet to serve it;
• a rule decides, per request, the minimum the content requires.

Four properties make it hold up:

• A rule has no way to name a provider, so it cannot be written to steer traffic at a chosen vendor.
• The strictest wins — the higher of what the rule requires and what the calling agent demands.
• Every comparison is “at least”, so a new level slots in between two already in use without invalidating a rule.
• Absence is not zero — a provider nobody classified meets no requirement, so one registered and forgotten never serves sensitive traffic.

If nothing qualifies, the request is refused — not served by the endpoint’s configured provider, not by a key below the requirement, not by the caller’s own credential. The refusal names nothing internal: no category, no detector, no level. It is recorded as the request’s own terminal event, so last quarter’s refusals are a query.

8. LLM spend and routing

8.1 What does the AI cost, broken down?

Finance needs a budget owner for AI spend, broken down to where it is spent. A budget is a figure that reconciles against the provider invoice.

Spend is accounted automatically per request, so cost lands per agent, per end customer and per LLM without anyone instrumenting the application. Because spend is a counter like any other, a rule can stop the work when a budget is reached, before the invoice.

A call the provider did not price is counted on its own, so a busy agent whose spend total stays flat shows up. Totals are kept far below the precision of a cent: an ordinary LLM call costs a fraction of a cent, and rounding it is how a ledger stops matching an invoice.

8.2 Are there limits on LLM use per request, per step and per action?

An agent in a loop spends until something refuses it. A dashboard reports the spend after the fact; a ceiling stops it at the time.

A counter with a ceiling is an ordinary rule — per agent, per end customer, per hour.

A ceiling can also be declared on the agent itself, and applies wherever that agent calls:

• two measures — the money it may spend and the number of requests it may make. The count matters on its own: a provider that stops reporting usage stops moving the money total while the money is being spent, and on the MCP gateway nothing is priced at all;
• three windows — a rolling hour as the brake on a runaway, and a calendar day and month as the budget someone reconciles against an invoice;
• a tenant-wide default, so an agent nobody configured still carries your organization’s limits;
• absence is the only way to say “no ceiling” — a ceiling of zero is refused, because the agent’s own off switch already says that (3.4).

A refusal on a ceiling is a policy decision: it names the rule and the ruleset version, says which measure and which window was crossed, appears in the audit trail, and can be backtested over past events before you switch it on (13.1).

8.3 Can a request be sent to a cheaper or safer LLM without changing application code?

The LLM list changes during the contract: a provider gets dropped, a cheaper one appears, one gets banned for a class of data. Choice of LLM has to be a policy change.

Yes. A rule can reroute a request that arrived for one LLM to another one, decided per request on whatever the rule can see — the tenant, the data class, the budget already spent.

How the choice is made:

• the rule states the risk level the content requires, and the strictest of that and the calling agent’s own level wins (7.5);
• candidates are filtered before any strategy runs: the provider must speak the dialect the request arrived in and must be trusted at least that far. Where nothing qualifies the request is refused;
• the LLM the caller named becomes a preference. Where a qualifying provider offers it, it is used untouched; otherwise the substitute answers, the reply names the LLM that actually served, and both the requested and the serving LLM are in the record;
• changing a provider’s risk level or declaring an agent’s level is configuration. No new ruleset version, nothing to re-approve.

9. Human review

9.1 Are multi-step and step-up flows supported — approve, block, challenge, second approval, escalate, log only?

Existing enterprise controls have more than two verdicts, so a control layer with two verdicts does not map onto them. In a step-up flow the agent waits for a person, and the wait can last hours.

Yes, through events.

• approve, block, log-only — covered by the three verdicts and declared actions;
• second approval and escalation — send the decision to human review, with a case behind it;
• challenge or re-authentication — the verdict and its tags go back to the application, which runs its own flow and emits a new event.

State between steps lives on the entity.

The MCP gateway holds the wait. A call that needs an answer outlives the HTTP request: the agent’s connection ends and the agent asks for the outcome later. A hold that names a question is answered by the user, a hold that names a case by an operator, and each hold carries its own deadline and what to do when it passes. The send that follows an approval is authorized at most once, so one approval cannot move money twice. Whether the send completes is the product’s own path.

9.2 What does human review produce that can be audited?

An approval that is not recorded did not happen. An auditor a year later needs the decision, the person, the time, and proof that nobody with database access changed it since.

The case carries a queue, an assignment and a priority. Cases are typed: the type decides the queue, the screen the operator sees and the actions open to them. The decision lands in the audit trail and can re-enter the pipeline as an event of its own, to be judged by rules in turn. A deadline per queue is optional and its behavior is declared. A decision made by a person and a decision made by the deadline are recorded alike, each named as what it was.

An approval is sealed like any other decision (11.3).

Part 2. How you govern the control

10. Audit trail

10.1 What does one decision record hold?

An investigation either reads one record or rebuilds the event from several systems. The record of a blocked leak holds the data that was stopped, so what it keeps of the prompt is itself a decision.

Each event gets one record per active version, plus one per version in shadow testing. Each record holds:

• the event as received and the state before it;
• which rules matched and which errored;
• every signal and every helper function, with its parameters and its result;
• the verdict, the state changes applied, the actions fired with their parameters;
• the response returned to the caller, and how long the evaluation took;
• the ruleset version and stream deployment that produced it.

What makes it evidence:

• One record is the whole decision. Nothing has to be assembled from a second source to answer why, so the record survives a retention policy that drops everything around it.
• The version is named by the digest of its own content, so the record says which text judged the event.
• Fields that carry secrets or personal data are encrypted in the database, and who reads the records at all is a grant (15.1).

To do for the team that answers

• Attach one anonymized record. One record answers this faster than any description.

10.2 Are security events logged as well as decisions?

A refusal is two things at once: a policy outcome and a security event. Recorded only on the policy side, it never reaches the security operations center, where every other attack signal already lands.

It is recorded like any other decision: what was attempted, which rule stopped it, on whose behalf.

Two checks a security team makes:

• A refusal is recorded as a decision to refuse, kept apart from a fault.
• Where a gateway made the refusal, everything the gateway states about the refused party is kept separate and marked as asserted by the gateway. The evidence chain (11.3) proves the record was not altered; it does not make an assertion true.

Under flood the volume is set by the attacker, so gateway refusal records are sampled per endpoint, at a rate the enterprise sets, and the rest folds into a per-minute summary: how many, by reason, by endpoint, and how many times the caller’s credential changed. Enforcement is untouched, and the full count stays in OpenTelemetry metrics.

10.3 How do records get to your SIEM, and how fast?

The SIEM is the system where the security team already watches the other logs, and it will not change for the control layer. Records the SIEM cannot read are records nobody watches.

Three ways out:

• Push as it happens, over syslog or HTTPS, to any endpoint. The message is formatted by the rule itself, so the shape the enterprise’s SIEM wants is a few lines of policy.
• Pull through the API, with filters over any recorded field.
• Follow a change feed, for a streaming consumer that wants every record as it lands.

A SIEM outage loses nothing: the records stay in the enterprise’s own database (11.2), and the other two ways out still reach them.

10.4 What retention is available, and can it differ by data type?

One retention period for everything is too short for the auditor or too long for data-protection law. Financial records are kept for years, and personal data is deleted when its purpose ends.

Retention is declared per kind of record and narrowed by condition. A decision record, a human review case and a raw event each keep their own horizon, and a shorter horizon for anything carrying personal data is a condition.

The horizon itself can be set per tenant, so one tenant’s regulator is answered without changing anyone else’s, and each tenant’s deletion records what it removed inside that tenant.

Old records archive automatically into the analytical tier (2.3). Deletion can never overtake the archive: the archive period and the deletion period are both resolved again immediately before anything is removed, so a policy change cannot delete records the archive had not yet copied.

11. Evidence integrity

11.1 Is a decision reproducible, and what is pinned?

An incident is often examined weeks later, after the rules have changed. Without the exact inputs and ruleset version, nobody can show why the decision came out as it did.

The input, the ruleset version, the state before the event and the time anchor are recorded, and the anchor is the ingestion time, so the same evaluation an hour later gives the same result. Rules that call nothing outside are exactly reproducible.

The version is pinned by a content digest: the event is admitted under it, and the evaluation is refused when the rules in force do not match, naming both.

A rule calling an LLM or an outside service is not exactly reproducible: the call is made again and the answer may differ. Input, version, state and time are still pinned, and the original call and its result stay in the record.

11.2 Who owns the records?

The evidence has to survive the end of the contract and the end of the vendor. Records the enterprise can read only through the vendor are not the enterprise’s records.

The enterprise does. The records live in its own database inside its own perimeter, the vendor has no production access unless granted, and export is a database dump. Copies go only where the enterprise sends them.

11.3 How is it known that a record was not edited afterwards?

A record the vendor or an administrator can change without a trace settles no dispute. Whoever controls the database can also rewrite its logs, so the proof has to be kept where they cannot write.

Every covered write is sealed as it happens by a proof record holding hashes and positions only. Those records are hash-chained, and the chain is folded into one Merkle tree per tenant with signed checkpoints. The tree, the checkpoint and the proofs follow published standards, so any conformant verifier reads them without Swiftward software.

Checkpoints can be witnessed to a write-once store outside the database that holds the records, held by the enterprise or its auditor, where the vendor cannot write. S3 Object Lock in compliance mode is one such store. The maximum age a checkpoint may reach unwitnessed is a setting the enterprise chooses, and the witnessed mode is refused unless the target, a signing key and that age are all in place.

Coverage is declared the way retention is: per kind of record and by condition, so the records with legal weight are sealed without paying to seal everything. A kind of record can also be marked so that a covered write fails while coverage is switched off — for an enterprise whose regulator does not accept a promise to keep it on.

11.4 Can the evidence be verified outside the deployment?

An auditor, a regulator or an end customer checks the records alone. Proof that only the vendor’s software can check asks the checker to trust the vendor.

Yes, two ways.

A signed checkpoint is enough. Anyone holding one checks that a record is in the tree, with the standard tooling for the format (11.3).

TRACE trust records are the portable per-session form, defined by the TRACE specification: a signed record of the identity that acted, the LLM, the policy in force, the data class touched and the tool calls made. The signature is Ed25519, checked against the enterprise’s published key, so the record is provably the enterprise’s. The specification’s own conformance suite verifies the record and the transcript it commits to, and the control layer passes it.

The portable record shows that a call was held and a case opened. Who decided and when stays with the enterprise, in full (9.2).

11.5 A person’s data has to be erased. Does that break the proof?

Deletion rights and tamper-evidence look like opposites. A lawful deletion and a hidden edit both leave a gap in the records.

No. Verification distinguishes a lawful removal from tampering by reading the sealed record of what was deleted (10.4). An absence covered by a completed deletion is reported as deleted by retention, an absence nothing accounts for as tampering, and the two are counted separately, so routine deletions never bury the one that matters.

12. Change control

12.1 How is a ruleset version managed?

A version in production has to be immutable by every route, including one that bypasses the application.

Only a frozen version deploys, and a frozen version cannot be edited: no administrator or API caller can change its text, its code or which ruleset it belongs to.

The running stream deployment is immutable too: a change creates a new stream deployment, and the previous one keeps its own activation and deactivation times. “What was live at 14:20 on Tuesday” is a record.

A change to a ruleset can itself be judged by a ruleset (maker-checker): the change is raised as an event, the same engine evaluates it against a policy written in the same language, and the version carries its own review state. Any save that changes the content returns the version to unreviewed and clears the earlier review decision, so an approval never survives the text it approved.

12.2 Can one person write a rule, freeze it and ship it?

A person who can both write and deploy a rule can switch off any control alone, and nobody sees the change before it runs.

Permissions are granular, so authoring a version and deploying it are separate rights held by different people. Activating a stream deployment is its own right, and it can carry its own approval step, the way a version change does (12.1).

Whoever did it is recorded either way: the version write, the status change and the stream deployment each land in the administrative trails with the actor on them (12.5).

To do for the team that answers

• Split authoring from deploying before the security review, and attach the role matrix. Two named people is what an enterprise accepts here.

12.3 Who reviews custom code a rule calls before it can run?

Custom code a rule calls sees every event the rule sees. Code nobody reviewed can change what the control decides.

A helper function that a rule calls is part of the deployment: it is declared, it ships with a version, and it goes through the same review and the same audit as the rules that use it. A rule author cannot add one. There is no marketplace where a third party publishes something the agent can reach. More than fifty ship built in (7.2), so the ordinary rule needs nothing new.

12.4 How does a change that affects the decisions become visible?

A change in behavior that nobody announced surfaces weeks later, in the enterprise’s own numbers. By then the cause is hard to find, because several changes have shipped since.

Every version is dated, named and attributable, and the difference from the version judging live traffic now is computed and kept.

Who tells you about a change, within what time and through which channel, belongs in the contract.

12.5 Is there an audit log of administrative actions?

Who changed the control and what the control decided are two separate records. An administrator who can edit the log of administrative actions can remove the trace of any change.

Two trails. Operations records who did what and when, as a tree, so a nested action groups under the request that caused it. Changes records what a value was before and after, rendered as a real before-and-after difference. Both cover rulesets, versions, stream deployments, users, roles, permissions and keys, and any object and operation can be added, reading included.

What answers the insider question:

• Both are written as part of the change itself, so work that was rolled back leaves no trail entry claiming it happened.
• Both are covered by the evidence chain automatically once it is enabled, each on its own chain, separate from the decisions’ chain. An administrator cannot edit the record of their own administration.
• Both outlive the tenant they describe. Who deleted an organization, and when, stays answerable after the organization is gone. Where someone acted on behalf of another user, the real actor is recorded beside the assumed one.

13. Testing and rollout

13.1 How is a new rule version tested against reality before it goes live?

A rule change that looks safe can still block real end customers or let real attacks through. Test data rarely shows this. The enterprise’s own past events do.

Backtest runs a candidate over a window of real past events and diffs its verdicts against the live version. Each run carries a reason, required by default, because the “why” belongs in the audit trail next to the result.

Two choices set what “would have” means:

• State — read the state recorded before each event, or let the candidate’s own effects accumulate over the window;
• Outside calls — reuse the result recorded at the time, which keeps the run deterministic and free, or call live and test against the world as it is now.

Shadow testing runs the candidate on live traffic beside the live version: evaluated and recorded, changing no state and firing no action.

Traffic split gives a version a percentage of live traffic, the arm picked by a consistent hash of a value on the event, so the same end customer or account always lands in the same arm.

13.2 How is divergence between versions analyzed?

A number like “2% of decisions changed” decides whether a version ships. It means nothing until it says 2% of which events, and which kind of change.

Per event, in the admin console, as a difference of live against candidate, down to the rule and the signal that made them differ, and exportable as a file for the enterprise’s own auditor.

In aggregate, through the API: the divergence share, a breakdown by rule, the rule most often responsible, and samples of mismatches.

What makes the aggregate defensible:

• The denominator is stated: the events both versions actually decided;
• three axes — outcome (verdict, matched rules, state changes, actions, response), verdict only as the conventional headline, and rule, for when a different rule reached the same answer;
• an error is its own dimension, counted apart from a changed verdict, so a fault cannot inflate the number a ship decision rests on.

Direction is reported too: a candidate that refuses more than live is stricter, one that refuses less is laxer.

13.3 Are staged rollouts supported, and what does rollout governance look like?

Raising a version’s share of traffic step by step limits how many end customers a bad version reaches. A change advisory board approves each step.

Deploy at five percent, watch, raise to twenty-five, fifty, a hundred — each arm carries its own percentage, and the control layer refuses a split that does not add up.

Every change goes through the API, so the enterprise’s own pipeline drives it and nothing depends on a person using a screen. Every change is in the administrative trails (12.5). A rollout step is a new stream deployment, and a rollback is the previous one, still intact (12.1).

Part 3. Enterprise foundation

14. Deployment

14.1 Which deployment models are supported?

A hosted control layer sends every prompt and tool call to a third party. A deployment model counts only if someone already runs it in production.

In the enterprise’s cloud, its data center, or bare metal. Every deployment runs inside the enterprise’s own environment. It installs as one image. A detector outside that image, where one is chosen, is installed on its own.

14.2 Can it run in an isolated network with no outbound internet? What stops working?

An isolated network gets tested by pulling the cable and watching what breaks. A license check, a telemetry call or a hosted detector shows up on day one.

Yes. Images are pulled once outside and mirrored into the enterprise’s registry. The control layer makes no outbound call of its own — only the ones a rule makes, under limits you configure. Witnessing checkpoints to a write-once store (11.3) needs that store reachable.

14.3 Which LLM does the control layer call, and does data cross a border?

Residency is a legal duty with a regulator attached, signed off by a data protection officer. It has to hold at every step the data takes, including a call a rule makes while deciding.

It may use none. Thresholds, limits, lists and counters call nothing, and then no data crosses a border.

Where a rule does call an LLM or a classifier, its location is configured — inside the enterprise’s perimeter, or a provider the enterprise chose and contracted. That provider is the enterprise’s subprocessor, under a contract the enterprise signs, and belongs on its data protection officer’s list.

14.4 How are updates performed in an enterprise-hosted install, and can they be rolled back?

A platform team runs the update on its own cluster. When the software version and the ruleset version move together, a security patch cannot ship without also changing which requests are allowed.

A rolling update of the image, the ordinary way for the enterprise’s own cluster. Ruleset versions are independent of the software version, so an update does not change a decision. A detector a rule calls is a versioned helper function (12.3), and the version it runs against is a parameter of the rule, pinned like any other.

To check it, backtest your live ruleset over its own past events on the new build before you accept the upgrade: the result is zero divergence (13.1). Anything else is the upgrade changing a verdict, named down to the rule.

15. User access and tenant isolation

15.1 Is there role-based access control, and how does it differ between runtime and administration?

A person who manages rules does not need to read the data the rules judge. When the two rights are one grant, every rule author can see production data.

Two layers.

• Administration — read, write and delete are granted per kind of object, and the roles are configured, so the enterprise’s own role names apply.
• Runtime — the tenant is the security boundary: evaluation runs in the tenant of the event, and a rule reads only that tenant’s data (15.3).

15.2 Which single sign-on protocols are live in production, and how does an account come into existence?

Single sign-on counts where it runs in production against the enterprise’s own issuer, because that issuer is what joiners and leavers already flow through. An account created by hand on first login is an account nobody removes on the last day.

OIDC in production, against the enterprise’s own issuer, with just-in-time provisioning on first login, so no account is created by hand. SAML through a bridge, a separate component.

15.3 How is tenant isolation enforced?

A tenant that reads another tenant’s data is a data breach for both organizations. A check each developer has to remember fails on the first developer who forgets.

A tenant is one organization: a customer of the product, or a business unit inside one. The tenant comes from the token, and a caller cannot set it or ask for another one. The filter is applied in one place for every read and every write, with tests behind it.

Because the deployment is the enterprise’s, it can satisfy itself: take a token for one tenant and try to reach another tenant’s rules, decisions and state through the API.

An enterprise that needs a database of its own runs its own deployment.

15.4 How is the admin console protected?

Whoever reaches the admin console can switch off every control. A separate login for it is a second identity system with weaker rules.

Sign-in delegates to the enterprise’s own issuer over OIDC (15.2), so the console inherits the multi-factor and conditional access already in force there, and a leaver loses it with the directory account. What the control layer adds: rights per kind of object under the enterprise’s own role names (15.1), and every administrative action in two trails (12.5).

16. Supply chain and key management

16.1 What is in the shipped image, and how is it verified before it runs?

The vendor’s own software supply chain arrives with the image. An enterprise registry has to verify the contents and the builder on its own, before anything starts.

Every image is built with a bill of materials and build provenance attached to the image itself.

• The build scans for known vulnerabilities and fails on a high or critical finding that has a fix.
• Dependencies are scanned on every commit.
• The published manifest is signed, and the signature is tied to the build pipeline, so the enterprise’s registry can verify who built it before it runs.
• Images are published for amd64 and arm64, each built natively.

16.2 How are secrets and keys handled?

Secrets already live in the enterprise’s own manager, with its rotation and its access records. A product that insists on a key store of its own becomes a second place keys are held, outside all of that.

Read from the environment, so any secret manager that populates environment variables works. Sensitive values stored as data are encrypted with a rotatable key.

16.3 What protects data in transit and at rest?

Whoever holds the encryption key can read the data. Encryption with a vendor-held key protects against stolen disks and leaves the data open to the vendor.

Everything runs inside the enterprise’s own environment (14.1) and the records sit in its own database (11.2), so transport and encryption at rest are the standards already in force there, configured at deployment. What the control layer adds: fields carrying secrets or personal data are encrypted by it (10.1).

17. Reliability

17.1 What uptime is committed?

On the synchronous path the control layer is a new single point of failure, and a vendor outage gets priced as an enterprise outage. Either a number goes into the contract, or availability belongs to whoever runs the software.

The control layer runs inside the enterprise’s environment, so uptime belongs to the enterprise’s own operations.

It holds no state between requests and runs in as many copies as are wanted. State and records live in the enterprise’s own database, under whatever high availability they already run.

17.2 What has to be restored after a failure, and how fast?

Recovery targets already exist for every other system the enterprise runs. A control layer that cannot be restored within them stops the products that depend on it.

Two things: the ruleset versions and the records. Both are rows in the enterprise’s own database. They fall under the backup policy it already has, recovery targets are the enterprise’s to set, and there is no vendor step in the path.

17.3 Is fail-open and fail-closed supported per rule or per category, and where does it apply?

Fail-open is a legitimate choice where it is declared. Each failure on the path is its own behavior to declare, and a health check on the engine alone misses most of them.

Five levels, each declared separately:

17.4 What happens to events that fail before evaluation?

An event that failed before any decision leaves a gap in the audit trail. An auditor asks about the gap, and an empty answer looks like missing records.

They land in a dead-letter queue with the payload and the error, searchable through the API. No decision record, because no decision was made.

18. Integration and vendor lock-in

18.1 How much of the application has to change, and can the check be bypassed?

A control an engineer can route around by changing one URL is a suggestion. Enforcement has to come from outside the application.

Pass-through needs no change. The product’s existing URL for LLMs, MCP servers or outbound traffic points at the gateway instead. Human review, step-up and challenge add application work: asking for the outcome and emitting the follow-up event (9.1).

Enforcement is a network endpoint. Close outbound traffic in the enterprise’s cluster to everything except the gateway and it becomes the only path a call can take — a control the enterprise’s own infrastructure team owns and can verify.

Configuring the policy is still work.

18.2 Is there a published input and output schema?

A published schema is what the application’s developers build against.

Yes. The input event is documented in the ingest API reference, part of the handbook delivered with the deployment. The response carries whatever the rule puts in it — matched rule, reason, tags, version — so the application acts on the verdict without a second lookup.

18.3 What is achievable in two weeks, and what usually causes delay?

Two weeks is a date somebody has already promised. A named list of what causes delay says what has to be arranged now, before the clock starts.

Two weeks buys one event type, a working ruleset, decisions recorded, one gateway in place.

Delay comes from three places, in this order:

• agreeing what an event contains
• getting the deployment approved
• connecting the SIEM

18.4 If a component is replaced later, what can be taken along?

Procurement writes the exit into the contract before signing. Rules that only one engine can run have to be rewritten by hand when the engine changes.

Policy definitions are declarative text. Decisions and state are rows in the enterprise’s own database. Both leave in a standard export.

19. Known limits

19.1 What limits remain once everything above is in place?

Every control layer has a limit, and a deployment plan has to work around it. A gap named at the start is one nobody meets at go-live.

• Attestation. The control layer runs inside the enterprise’s own environment, so it falls inside the scope already audited there. It carries no attestation of its own.
• Latency under load is a number the enterprise measures in its own environment (2.2).
• Reports come from complete audit data, formatted by the enterprise to the standard it files under.
• Sub-millisecond decisions on a trading hot path sit outside what the control layer was built for.
• Very large numbers of tenants in one shared pool sit outside what the control layer was built for.

Built for agent control, payments, trust and safety, internal operations, audit-heavy work, and on-premise deployment in regulated environments.

What this document does not answer

Everything above is the control layer. The rest of the review sits outside it.

• The LLM and its data. Which LLM, what it was trained on, whether customer data is trained on, accuracy, bias testing.
• Staff training and internal AI policies. What the team has had, and how AI use is written down. A document is expected for each.
• Certifications, or what goes in the file when there are none.
• The reviewed product’s own supply chain. Bill of materials for what it ships, how fast a fix lands by severity, and what happens to a version no longer supported.
• Contract terms. Liability, indemnification, incident notification in hours, continuity if a small company stops existing.
• Territory. The EU AI Act, for one, sets training and documentation duties that do not exist elsewhere.
• Expectations beyond these questions. Every enterprise adds questions of its own.

Stuck on some of these, or have others? Send them over — happy to help.