How it works
Every request to or from your AI passes the same four checkpoints, in the same order, and comes back with a decision and the reasoning behind it. It works alongside your existing identity provider.
ops-copilot → crm-tools-mcp : search_ticketsreason: "allow-copilot-crm-read; judge: routine ticket search"Want to see it on real traffic? Explore the live preview.
Step by step
Every caller (an agent, a tool, a service or a person’s session) signs each request with its own Ed25519 key. AISec checks the signature, the key’s status and a one-time nonce with a timestamp, so a captured request can’t be replayed.
Outcome:Unsigned, expired or replayed → deny
Deterministic rules decide who may call whom, for which actions, under which conditions, how often, and how deep a delegation chain may go. When several rules match, the strictest wins. When none match, the answer is deny. The same input always gives the same answer, so these rules can be reviewed and tested like code.
Outcome:Deny rule matched → deny (final)
A safety-focused model reads the request against your written policy and asks: does the intent and content fit what this caller is supposed to be doing, and does it still serve the task that started the chain? It can tighten the decision to escalate or deny. It can never loosen it. If it is unavailable, a fallback judge takes over.
Outcome:Suspicious → escalate or deny
The decision, its reasons, the request’s fingerprint and the policy version are written to a hash-chained ledger. Blocks are signed by the gateway, and AISec is designed to anchor their roots to a public blockchain.
Outcome:Every outcome is recorded, including denies
Allowed requests are forwarded to their target. Whatever the outcome, the caller receives the decision and a machine-readable reason, so agents can correct course instead of retrying blindly.
Outcome:Allow · Deny · Escalate, always with a reason
Three directions
The pipeline is the same in every direction. What changes is the question each checkpoint asks.
research-agent → payments-api An agent wants to act on a real system: query a database, call an API, run an MCP tool. AISec checks that a rule allows that agent this exact action, with these arguments, and that the request matches its task.
crm-system → research-agent Your systems hand work and data to an agent. AISec checks that this system may send this task to this agent, and the judge reads the content for instructions an agent shouldn’t follow before it acts.
research-agent → summarizer-agent One agent delegates to another. Each hop is signed and linked to the one before it, rules can look at the whole chain, and policy caps how deep the chain may go.
Defence in depth
Models can be wrong, and they can be manipulated. So the judge has only one direction it is allowed to move a decision: stricter.
Deterministic rules run first. If a rule says no, the answer is no: the request is denied and the judge is not even asked. A prompt injection that fools the model therefore can’t unlock anything the policy forbids.
When the rules allow a request, the judge reviews it. Its verdict is combined with the policy decision by taking the stricter of the two. If the judge is unavailable, a fallback judge takes over.
The judge works from a policy written in plain language, with numbered sections such as SP1 for prompt injection and SP4 for scope creep in a delegation chain. Its reasons cite those sections, so a reviewer can see exactly which concern was raised.
The judge runs on an open-weight safety model, so it can run on your own infrastructure. Your request content doesn’t have to leave your environment to be judged.
The result: the AI judge adds protection on top of your rules but can never remove any.
| Policy says | Judge says | Final |
|---|---|---|
| Deny | not consulted | Deny |
| Escalate | Allow | Escalate |
| Escalate | Deny | Deny |
| Allow | Allow | Allow |
| Allow | Escalate | Escalate |
| Allow | Deny | Deny |
# Simplified: how the final decision is formed
severity: allow < escalate < deny
decide(request):
identity = verify_signature_and_nonce(request)
if identity.failed: return deny(identity.reason) # unsigned, replayed, unknown caller
matches = matching_rules(request) # caller, target, action, flow, conditions
if not matches: return deny("no rule allows this") # default verdict
policy = strictest(matches) # deny > escalate > allow
if policy == deny: return deny(policy.reason) # final, judge not asked
if not policy.judge: return policy # e.g. low-risk reads
judge = ai_judge(request, written_policy)
if judge.unavailable: judge = fallback_judge(request, written_policy)
return strictest(policy, judge) # the judge can only move rightPolicy as code
Policies are plain YAML files. The dashboard shows every rule, its effect, its conditions, whether the judge reviews it and how often it matched.
Verifiable history
A log you have to trust isn’t evidence. AISec’s ledger is built so that anyone with the right proof can check it, without having to trust us.
Each decision record (who, what, outcome, reasons, timestamp) is hashed. The hash is a fingerprint: change one character and it no longer matches.
Records are grouped into blocks with a Merkle root. Each block includes the hash of the block before it and is signed by the gateway, so rewriting one block breaks every block after it.
AISec is designed to publish the ledger’s roots to a public blockchain at a regular interval. After that, nobody, including AISec, can rewrite the history before that point without it showing.
An auditor gets a decision record, its Merkle proof and the block header. They can check the record is in the block and that the block’s root was published, without access to our systems.
Only hashes are anchored: the content of your decisions never leaves your ledger. Anchoring proves records weren’t changed after the fact. It doesn’t prove that a decision was correct; that’s what the reasoning and the trace are for.
Fits your stack
AISec is designed to accept the agent and workload identities you already issue, for example from Microsoft Entra ID, Okta or AWS, and to add per-hop signing, policy, explained decisions and a verifiable record on top.
AISec is in early access. Look around the live preview yourself, or book a 30-minute walkthrough with your own use case.
Not ready yet? Join the waitlist.