The questions, answered plainly.
What is pre-execution governance for AI agents?
It is deciding what an agent may do and say before it acts, instead of recording what it did afterward. Our engine resolves the owner's rules at the moment an action is proposed and returns permit, hold, or deny. Nothing executes without a permit.
What is an Agent Operating Procedure (AOP)?
A structured, versioned, machine-enforceable rule for what an agent may do and say, and what happens when it steps outside that. You author them in our dashboard or by API; our engine enforces them automatically.
What is shadow mode?
A per-tenant mode where our engine computes and records every decision without blocking anything. It builds your Shadow AOP Ledger: proof of what governance would have caught, and the raw material for calibrating your rules before you enforce.
Does the agent ever hold credentials?
No. On our platform the agent emits a proposal and holds zero keys. Connectors execute permitted actions server side with credentials stored on our side, only against a valid permit.
What are permit, hold, and deny?
The three verdicts every check returns. Permit proceeds, hold waits for a human, deny stops. The input and response checks return allow, escalate, and block, which map to the same rails.
How fast is the action check?
Well under ten milliseconds at p95, fully deterministic, with no model on the path.
What happens when an agent exceeds its limit?
The action check returns hold or deny before anything changes. A held item routes to a human with full context; everything within the limits keeps running.
What is the difference between pre-execution governance and observability?
Observability records what happened so you can investigate. Our governance decides what may happen before it does. They compose: keep your traces for quality, put our gate in front of consequence.
Can it govern any agent?
Yes. An agent from a vendor platform, one your company built, or an open-source agent you host yourself: anything that can call three endpoints can run through our gates.
How do I make an AI agent follow company policy?
Turn the policy into AOPs: limits on actions, rules on responses, packs for your jurisdiction. Our engine enforces them on every proposal, every time, and the ledger records the proof.
How does Selah handle AI hallucinations?
We do not stop a model from hallucinating; no one can. We stop hallucinations from acting and speaking: every reply is checked against the owner's catalog, allowed claims, and required disclaimers before it sends, a grounding layer judges whether it matches what the agent actually knows, and a hallucinated action hits deterministic limits before it executes.
Can I finally trust an AI agent with real work?
Yes, because the trust is structural. The agent holds zero credentials, every consequential act passes our gate, and our shadow mode gives you evidence from your own traffic before you enforce. You are not trusting the model to be right; you are trusting the gate to be closed.
How do I keep an AI agent honest?
Give it a source of truth and a gate. On our platform you load the catalog, the allowed claims, and the disclaimers as response AOPs; our engine checks every reply against them, and what is not grounded is blocked or escalated to a person.
What is fail-closed?
The posture of our action path: if our engine does not permit, or cannot decide, the action does not run. Screening layers fail open so they can never silently kill legitimate work.
Is this for individuals too?
Yes. A private tenant puts our gate in front of a single self-hosted agent, with holds arriving as a panel alert and an email. It is the lightest path in.
What are the three gates or moments?
Selah governs at three moments: input, action, and response. The input check (POST /v1/gate/check) screens incoming messages and fails open. The action check (POST /v1/evaluate) is deterministic, runs in well under ten milliseconds, and fails closed. The response check (POST /v1/validate/output) runs hard rules that fail closed, then a model layer that fails open.
How does Selah handle multi-jurisdiction compliance?
Jurisdiction is the second of the five layers, just under compliance. Compliance and jurisdiction packs let a tenant inherit governance for where it operates rather than starting from zero. Coverage is being built for Colombia, the Dominican Republic, Mexico, Brazil, and Peru.
What is the Shadow AOP Ledger?
The Shadow AOP Ledger is the record built in shadow mode of what your AOPs would have decided, without enforcing. It is your proof and your raw material for authoring AOPs. You turn its decisions and gaps into the rules you eventually enforce.
What is the difference between an enterprise, platform, and private tenant?
Tenant type changes how escalations are handled, not the decision logic. An enterprise tenant gets a review queue inside Selah plus email, a private tenant gets an alert in the Selah panel plus email, and a platform tenant resolves escalations in its own product over a webhook. For a platform tenant, Selah stores none of the conversation.
Does Selah store the conversation?
It depends on tenant type. Enterprise and private tenants keep the held item and its context inside Selah so a person can resolve it. For a platform tenant, Selah stores nothing about the escalation, and the context travels in the webhook to your own product.
How is Selah different from guardrails in a system prompt?
Guardrails in a system prompt are a suggestion a model can ignore or be talked out of. Selah is an external decision layer, evaluated as a pure function outside the model, so the verdict does not depend on the model's mood or the latest jailbreak. If the engine does not permit an action, it cannot happen.
Which check actually stops a bad action?
The action check is the gate that matters. Before the agent touches money, data, or a system, the proposed action is resolved against your rules and the check fails closed. A permit returns a decision identifier that a connector requires to execute, so a permitted action can only run once, server side, against a verdict that actually exists.
How do I stop an AI agent from refunding too much?
You write an Agent Operating Procedure that caps what the agent may refund, and the action check enforces the cap before any money moves. If the agent proposes a refund above the limit, the verdict is hold: nothing is paid and the item waits for a person. Because the check is deterministic and runs before execution, an over-limit refund never reaches your payment system in the first place.
What is fail-closed for an AI agent?
Fail-closed means that if the engine cannot return a clear permit, the action does not happen. The deterministic action check is fail-closed by architecture, so no permit means no execution, even if the engine itself is unavailable. It is the opposite of failing open, where an unanswered request would be let through.
Do AI agents need credentials?
No. The agent proposes actions, the engine decides, and server-side connectors execute, so the agent never holds credentials or touches a system directly. Connectors run with encrypted, write-only credentials the agent never sees, and they only execute against a permit the engine actually issued. If the engine does not permit an action, there is nothing for the agent to do.
Can I govern an AI agent without changing its model or prompts?
Yes. Selah is an external decision layer reached over HTTP, not a library inside your model, so any agent that can make a request can be governed without retraining or rewriting prompts. You point the agent at the input, action, and response endpoints, and the verdicts hold no matter which model or framework you run.
How do I add human approval for risky AI agent actions?
Set the threshold in the relevant Agent Operating Procedure, and the action check returns hold when a proposed action crosses it. A held item does not execute; it waits in a review queue, or a webhook for platform tenants, where a person sees the full context and approves or denies it. Routine actions still pass instantly, so only the risky ones wait.
How do I stop an AI agent from promising something off-policy?
The response check runs before any reply reaches a person, enforcing hard rules such as required disclaimers, banned phrases, and prices that exist in your catalog. Hard rules fail closed, so an off-policy promise is blocked or escalated rather than sent. A model layer then checks grounding and tone, and it fails open so it never silently drops a good reply.
How do I prove to an auditor or insurer what an AI agent was allowed to do?
Every decision the engine makes lands in an append-only, hash-chained audit record that cannot be quietly rewritten. That record is the artifact a regulator or insurer actually asks for: what was proposed, what was allowed or denied, and under which rule. Some insurers have begun asking for proof of pre-execution governance before they will write coverage.
Why must the check happen before the action and not after?
Once an action has run, money has moved, data has left, or a promise has been made, and a log only tells you afterward. A check that happens before execution can still return hold or deny, so the bad action never lands. That is the whole point of pre-execution governance: the decision moves in front of the action.
Still have a question?
The docs go deeper on every answer here, and we are happy to talk through your case.