What Underwrit does, one part at a time.

Every tool call is decided before the tool runs, not logged after.

The call goes to the data plane first. Checks run in the same order every time and each reason carries a stable code, so the same call under the same policy always gets the same verdict: allowed, recorded, held or denied. A gate that does not answer counts as a refusal.

Content can suggest an action. Only people can authorise one.

Underwrit tracks where each value that carries authority came from: the recipient, the amount, the target. A value that appears only in something the agent read, such as a web page, an inbox or a ticket, is held for a person. Reading outside content marks the session, and the mark stays.

A credential or account number the session read, sent out inside a message, is held.

The engine looks inside every text argument for credential shapes (cloud keys, tokens, private keys, passwords in URLs) and for IBANs and wallet addresses. It holds one the session read that the user's own request did not contain, whatever the tool is called. Reasons name the kind, never the value.

It checks shapes we wrote ourselves, measured on our own 20-case set.

A short list of rules in plain words, not a model's judgement.

Start from one of 45 templates (coding agents, MCP, Kubernetes, Terraform, cloud IAM, refunds, HR, SOC 2, PCI DSS, HIPAA, the EU AI Act and more) and set your limits, payees and quorums. A template never switches enforcement on and never loosens a rule you already wrote. "Ask the gate" shows what a call would get under a draft, writing nothing.

Reads run, writes wait for a person, admin is refused, without listing every tool.

Each tool is filed as Read, Create, Update, Delete or Admin the first time it is seen: your own choice first, then a table of names that mislead, then the verbs in its name. A name with no verb we know counts as a change, never a read, and is shown first as guessed so a person can confirm it. The starter template gives each class allow, approve or deny, and every other check still runs.

An agent is not shown a tool it can never use, so it does not plan around it.

Before the Underwrit Gateway answers the agent's tool list, it asks the plane which tools are refused whatever the session holds: the deny list, a class the policy refuses, a blocked MCP server or a stopped agent. Those are left out. A tool that would only be held stays listed, because a person may approve it. Each change to what an agent is not shown is recorded, and the call is still decided if the agent names a hidden tool anyway.

Monitoring only hides nothing; it reports what would have been hidden.

See what enforcing would do before it stops anything.

A new environment starts monitoring only: verdicts are recorded and nothing is blocked, and the console says so on every page where that changes what a verdict means. A hold reads "Would require approval" and a refusal "Would block", and counts keep each decision in the mode it was decided in. Before you switch to enforcing, the what-if replays your recorded traffic as if enforced, and reports how often agents would be stopped, the people-minutes it would ask for, and the tools to narrow first. Asking changes nothing.

Run Underwrit next to the controls you have, then read what it would have held or blocked.

Name the environments and the trial keeps them monitoring only for 14 days, so nothing is stopped. The report counts what would have required approval and what would have been blocked, how many of those ran anyway, by day, tool, agent and reason, with the riskiest examples to open. It carries no argument values, so it can go to someone who may not see the traffic.

Follow one payment request from the agent's ask to the record, before connecting anything.

Set up opens with a worked example drawn with the console's own pages over fixed data: the request, the decision and why, a review that compares the recipient with where it came from, and the evidence it leaves. Nothing is sent or recorded. Then setup is one workflow: pick your stack, get one recommended integration, and see its first event arrive. The approval step follows your role, and Python and TypeScript setup end in a connection check you can run.

Rules for confidential data, money and chains of agents.

Mark which tools return confidential data. Once a session has read from one, sending anywhere outside your allowlist is held. Spend limits hold the call that would take a session past its budget, and a chain of agents deeper than you allow is held.

A sidecar, the gateway you already run, or twenty lines of SDK.

The Underwrit Gateway carries MCP and the agent's model traffic, so a proposed tool call is decided before the agent even receives it. Envoy, Istio, Kong, agentgateway, Portkey and LiteLLM can ask Underwrit too, as can the Claude Code hook and the Python and TypeScript clients.

Not an LLM gateway: no provider routing, caching or rate limits.

The data plane decides next to your agents. The cloud never sees an argument.

The control plane is never in the decision path. Policy flows down to each data plane, and only counts and digests go up. If the link is cut, the data plane keeps deciding from the policy it already has.

The reference an assistant reads before it writes the integration, generated from the code.

llms.txt indexes the site, openapi.json is generated from the plane's own route table with the grant and plan of every route, a read-only MCP server answers routes, reason codes, plans and policy fields from the installed package, and Get started gives a block to paste into AGENTS.md. The MCP server holds no token and changes nothing.

Approvers sign this call, under this policy, until a deadline.

The approval binds a fingerprint of the tool, its arguments, the policy version and an expiry. Just before running, the runtime claims it: changed arguments are refused, and the matching claim runs once. Quorum rules apply: the person who asked and the policy's author cannot approve, and approvers can be asked to state who is paid and how much before their answer counts. An approver can also request a revision: a refusal whose reason goes back to the agent, so it can try again. The reviewer never edits the call.

One page per task: what was intended, what a person authorized, and what was observed.

An agent proposes a task contract; a person authorizes it exactly as proposed, refuses it, or asks for a revision whose reason the agent reads. In Kubernetes the cluster itself enforces it at admission: only the named fields may change, a set number of times, until it ends or is revoked mid-task. The enforcer reads each change back and checks the rollout with its own identity, so "observed" and "verified" never rest on the agent's word.

Kubernetes restarts and scaling only. Reads and exec are outside what admission sees.

The approver's own device signs the exact action.

A passkey (WebAuthn) signs the approval's fingerprint, so the record shows that a person approved this action, not merely that someone's session was signed in. Enterprise can require a passkey for named environments, such as production.

Each hold comes with the facts, built from the record rather than from what the agent says.

Where each recipient, amount or target was found; the policy then and now; outside content read since; whether the tool definition is pinned; the connector's coverage; the task budget left; and a list of what nobody knows yet. Agents cannot read the card.

Every approval request opens with what the agent wants to do, in one sentence.

"billing-bot wants to send money (recipient, amount) through bank in production." It is built from the record, never from text the agent wrote, and it reads the same in the console, Slack, Teams, phone notifications, PagerDuty and Jira, so an approval given anywhere was given to the same words. Values appear only when you allow them to leave the plane in every channel.

Approve in the console, Slack, Microsoft Teams or on your phone.

In Slack, approving needs every argument ticked. Team adds answering inside Teams and push notifications for every hold. Every channel goes through the same quorum, exclusions and binding, and the record says how the person was identified.

The Teams bot is tested against a stand-in of the Teams service.

Page on-call, open a ticket, or approve on the authenticator already on your phone.

A hold pages PagerDuty and opens a Jira issue; both close when the decision is settled, wherever it was answered, and neither approves anything. With Duo Push or Okta Verify, named approvers answer on their phone: the push goes to their own directory account, not a chat handle, Okta's answer must be a signed token that names them, and a deactivated person is never asked. A hold that needs fields acknowledged by name waits for the console.

Tested against stand-ins of PagerDuty, Jira, Duo and Okta.

Is anyone reading before they approve?

Approval load shows holds per day and the tools whose holds are almost always approved, which are the first rules to narrow. Team adds attention: time to decide, per person, to tell a review from a rubber stamp.

Find out whether reviews catch what they should.

With the organisation's consent, a copy of a recent real hold is sent with one flaw planted, a changed recipient or amount, and scored on whether it was refused. A drill can never run: any claim of it is refused, whether the environment enforces or only monitors. Results are aggregate unless per-person results are switched on, and the person is told at once.

A held step waits safely instead of timing out.

In Restate, DBOS or Inngest, a held step suspends and resumes when someone answers, so the agent neither polls nor gives up.

Each engine is tested against a stand-in of it.

Rules signed by their publisher, scored on your own traffic first.

Each of the 45 templates past the first seven is also a signed pack, 42 in all. Before you apply one, it is scored on your last 30 days of recorded calls. Merging keeps the stricter value everywhere, so a pack can never widen an allowlist or loosen a rule. Enterprise packs cover treasury, the EU AI Act, DORA and SEC 17a-4.

Know which MCP servers agents use, and hold the ones nobody approved.

A catalogue with trust scores from the official MCP registry, and a scan of tool definitions for poisoning and hidden instructions. Team enforces an allowlist at the gate: a call to a server nobody approved is held for a person. Approving pins the definitions that were reviewed, and every decision names the server and the approval it relied on.

The scan looks for known patterns of tool poisoning, not every possible one.

Invented, brand-new and lookalike packages are held before a coding agent installs them.

The gate asks PyPI or npm first. A name that does not exist, was first published days ago, or looks like a popular one (expres for express) is held for a person rather than failed, so work is not blocked and someone decides. Team adds organisation rules and a feed of invented names, which keeps holding a made-up name even after somebody registers it.

Not a malware scanner: package contents are not read.

public, internal, confidential, regulated.

Label data by class. Once a session has read a class, the gate holds sending it anywhere that class may not go. Declassifying is an action of its own, on the record.

One limit across every session and sub-agent in a task.

Splitting the work across sub-agents does not multiply the budget. Pending holds and uncertain outcomes count; refused and failed calls are released; an amount that cannot be read is held, never counted as zero. A task is joined by a verified delegation receipt or by declaration, and the view says which.

Budgets are amounts read from the call's arguments, not money the target system moved.

Trace a bad source forward to every memory and decision it reached.

Every memory write records what the writer had read. Enterprise can revoke a source: every memory derived from it is quarantined, reads of those memories are held, and the sessions that read them are listed. A person closes each quarantine as repaired or released.

Inferred lineage means "the writer had read it", not proof the memory came from it.

We test our own claims, and publish the misses.

Four suites run against claims written down first: 58 labelled security cases, the templates, 25 tamper cases and decide latency. Under the reference policy, 42 of 42 attacks were stopped with 1 false hold in 16 harmless look-alikes. The stock policy, with nothing declared, stops 28 of 42; we publish that too.

Tonight's attacks, built from today's traffic.

Attacks are generated from the day's recorded calls and run against your policy, so the cases look like your agents' real work rather than a generic list.

Did the agent fall for it, and did the gate catch it?

Attacks are planted in outputs this deployment really recorded, aimed at tools your agents really have. Whether the model completed the attacker's goal and whether the gate would still have stopped it are counted apart. Enterprise signs the report, grouped by OWASP LLM Top 10 and MITRE ATLAS.

Runs against a real model endpoint were tested only against a stand-in.

Attacks tuned against your agent, scored on material the tuning never saw.

Fixed attack lists overstate defences. A campaign tunes attacks using what your agent and the gate did, then scores the best ones and a fixed baseline on a held-out split, alongside how often harmless work still completed and how many holds were false. A candidate policy can be judged without being put in force.

A search over known tricks, not a human red team: a low score is a lower bound.

What the policy can never do, checked over every case.

State a property, such as "no payment over the limit is allowed without two people", and it is checked over every case the policy can tell apart rather than over a handful of examples.

Is the model you pay for the one that answers?

Scheduled probes compare canary answers, the reported model and token counts with what was expected. While a provider's latest check is failed, incomplete or stale, the agents that use it have their consequential actions held. Enterprise records, in each decision, the check it relied on.

These are signals, not proof of which weights served a given request.

Edit, drop or reorder one entry and the record stops verifying.

Each entry carries the hash of the one before it, in a Merkle log (RFC 9162). Your plane signs checkpoints of the log with its own Ed25519 key, which can come from Vault or a KMS so it never sits on disk. A lawful erasure shows as an erasure, with who authorised it and why, instead of looking like tampering. Try breaking it on the home page.

Deletions show, and nothing can be backdated.

A witness countersigns the log's size and checks that it only grew since it last looked. A time authority stamps when each checkpoint existed (RFC 3161). Free runs its own witness; Team adds the hosted witness, timestamps and a guaranteed quorum on the public witness network, where independent operators cosign, k of n.

The public network needs independent operators; none is offered yet.

A pack carries its own verifier. No account, no network, no trust needed.

A pack is a zip of entries, proofs and verify.py. An auditor runs it on their own laptop, or drops it on the browser verifier, where nothing is uploaded. Both verifiers are MIT licensed, and tests hold them to the same verdict on every format and on tampered packs.

A pack proves the entries present were not changed, not that the record is complete.

Every pack says which build of Underwrit made it.

The edition, the licence, the limits and whether the install is within them, and whether the code is the release Underwrit signed. The verifier warns about a modified build, and verify.py --require release fails anything else.

What the tool returned, beside what the agent said.

At the proxy, the tool's real answer is recorded as the decision's outcome. An outcome posted with an observer token is marked independent; one the runtime reports is marked as the runtime's word, so the two never blur.

A gate only governs what passes through it. Coverage checks what did not.

Per connector, what an independent observer saw happen is compared with the decisions that allowed it, and the view names what is missing: undeclared, unmediated, unobserved, a stale observer, or an effect nobody decided. Team runs seeded qualification tests and can hold consequential calls on connectors that are not covered. Enterprise signs a statement that also lists what it does not claim.

Only the Kubernetes audit adapter is built; others post the same event shape.

A certificate that a connector's matching binds the right action, and nothing else.

The connector's matching rules run against synthetic fixtures, including a different resource kind with the same name, a name in an unrelated argument and a change of case. Every consequential tool needs a target template that names the resource kind, such as {namespace}/pods/{name}. The certificate is bound to the route and the approved tool definitions: any change withdraws it, and lost coverage or 30 days lapses it. The coverage statement includes it.

It states its scope: synthetic fixtures and the live qualification, nothing beyond them.

Failed, held and refused rates per agent, against a budget.

The rates come from the gate's own records, so there is nothing new to instrument, and "held" and "refused" are rates no tracing tool sees. Team sets error budgets, puts each breach on the chain, compares before and after a change marker, and signs a statement.

No paging: feed the rates to the alerting you already have.

Timeline and blast radius in one click.

The sessions, decisions, approvals and outcomes involved in an incident, in order, with what each one touched, exported as a signed bundle.

Was it the rule or the model?

Each decision records a digest of the policy it was judged under, and that policy is kept. Enterprise re-runs a past decision's gate under that exact policy, and its model call against a target an admin configured. A replay is called exact only when the request, the declared weights and the sampling all match; otherwise it is labelled a comparison.

Replays were tested against a stand-in model endpoint.

Where a different policy would first have changed the outcome.

Give a candidate policy, or decisions whose output to drop, and every session in the incident is re-walked. It reports the first step where the verdict differs, how many actions that ran would have been stopped, and how many held or refused would have been freed. Observed, reproduced and suspected are labelled apart.

An incident becomes a case every later policy change has to pass.

Add a decision from an incident as a case, with credentials replaced, and say whether the gate must stop it or let it proceed. Every policy write goes through one gate that replays the cases first, Cedar imports included. A change that newly fails a gated case is refused unless somebody records why, a stop case passes only when the denial is enforced, and a case that cannot be evaluated refuses the write instead of passing.

Live inputs (an outside decision point, freezes, the model) are not re-run, and each run says what it replayed. Fleet changes are checked on arrival, not refused before they apply.

Success reported is not success checked.

Name the tools whose outcome must be checked, and a check opens when they report success; one past its deadline goes on the record and can hold the target. Read-back probes for Kubernetes and Terraform settle a hold from the real state, and a read that fails never clears it. A repair is proposed as a new decision that always goes to a person.

Pick a framework, draw a reproducible sample, test, sign.

An engagement is a framework, a period and the controls in scope. The sample is random or risk-weighted and can be drawn again from its recorded seed. Test steps are proposed from the chain (named approver, argument binding, separation from the requester, approval before execution), the auditor concludes each one, and the workpaper is signed. Mapped to SOC 2, ISO/IEC 42001, the EU AI Act and NIST AI RMF.

The mappings are our reading. Scope and sufficiency are the auditor's call.

Which OWASP Agentic, NIST AI RMF and MITRE ATLAS items Underwrit acts on, here, with the evidence.

For each item in the three catalogues: the mechanisms that bear on it, whether each is in place on this install, the reason codes and record entries that show it acting in the period, and what Underwrit does not do about it. Each session's evidence pack names the items its decisions bear on.

Coverage, not compliance: our reading, not a statement that a framework is met.

Statistically sized samples, each with an inclusion proof.

Sample sizes are computed for the confidence the firm needs, every sampled entry comes with a Merkle proof against a signed checkpoint, and a firm's clients are kept as separate teams with their own grants.

EU AI Act Art. 12 and 73, SEC 17a-4, FINRA 4511, DORA.

The record exported in the shape each rule asks for, signed, with the entries it was built from.

Each mapping is our reading of the text.

Classification, obligations and the Annex IV file, written from real records.

The oversight, record-keeping, risk and post-market sections are written from holds, the named people who answered them, refusals, policy versions, proofs and incidents. Each statement cites the entries it came from, and the file is signed and anchored to the chain. What only you can say is marked for you to fill in.

Evidence assembly, not legal advice. The classification is our reading of the Regulation.

Signed statements of what the gate did, and how it is set up.

A period attestation counts decisions by verdict and reason over a window, anchored to the chain, so anyone with the key can check the signature and recompute the numbers. The deployment check signs a result of this install against a certification profile, with a badge.

How your agents are governed, signed, metadata only.

Holds, refusals, test results and controls, never arguments, shared by a link you can revoke. Enterprise adds a continuous feed.

A claimed loss, checked against the record.

Was the action held, and then run without the approval it needed? The record answers that question for a claim.

Cover needs an insurance carrier; it is not offered yet.

Checkpoints attested by the enclave that made them.

The gate runs inside a confidential computing enclave and its checkpoints carry the enclave's attestation, so the host's operator cannot sign for it.

The attestation is simulated today; hardware attestation is next.

Who an agent acts for, and how it has behaved.

A signed statement another company checks offline against your published key. Anyone can verify one with the MIT verifier; Team issues them.

A passkey grant that holds across company lines.

A person signs a grant with their passkey, and every agent that acts under it carries the chain back to them, so a partner's gate can see which human the authority comes from.

Both companies' gates co-sign one record.

When your agent's action lands on another company's system, both gates decide, and the action proceeds only when both allow it. The single record carries both signatures.

AP2 mandates and x402 requests checked before an agent pays.

The payee, the amount and the limits in the payment request must match the mandate the person signed; anything else is held.

The whole decision and evidence path, for one deployment.

An environment is one data plane deployment, however many replicas share it. The limit is checked only when a second team or node is created, which answers with a link to plans. Nothing already running is ever refused, slowed or cut off by it.

Several environments under one organisation on Underwrit Cloud.

Roll one policy out across environments, see every node and its build in a fleet view, and give people different roles in production and staging. The hosted witness and RFC 3161 timestamps come with it.

From a token to your identity provider.

Free signs in with tokens or OpenID Connect. Team adds members, invitations and sign-in by email link, with no passwords. Enterprise adds SAML and SCIM, and a deprovisioned person is refused by your own data plane.

Stop every agent of one kind with one action, and name the person answerable for each.

File each agent under a class: every agent made from the same template, prompt or runtime. Stopping a class refuses new proposals from all of them, and decisions already waiting can no longer be approved or claimed. Each agent can name a sponsor and an owning team; where the policy requires one, an agent without a sponsor, or whose sponsor the directory deactivated, is held. Stopping is never plan-gated.

Use the identities and detectors you already run as inputs to the policy.

A session presents its Entra Agent ID, SPIFFE or Teleport token; the plane checks it against the issuer's keys and records which identity stood behind the session. Where the policy requires one, an unverified session is held and one presenting another agent's identity is refused. Lakera, Lasso and Cisco AI Defense verdicts on the session's content can hold or refuse what follows, and can be required to carry the detector's own signature.

Tested against stand-in issuers and detector responses.

How far one agent reaches, and what one contract would let it change, before you say yes.

For each agent: every tool it reached, its action class, and what the current policy does with it, changes that run without a person first. For a contract or proposal: each object it may change and how, at most how often and until when, the tools it grants, and other live contracts on the same objects. Counts and names from the record, not a score.

Underwrit does not read your clusters or systems, so what depends on a target is not listed.

For organisations with many teams, auditors and rules about where data lives.

Several teams by licence, Cloud or self-hosted; audit-firm engagements where a firm and its clients are separate teams; regions; customer-held keys; controls on support access; an SLA and a DPA.