What Torvant does, how you can check it, and what is not done yet.
The detail behind the home page, in plain words. Each part says what it does, how you can see it, and its limit.
A grant is a short, signed permission.
Thirteen things are inside it. Scroll the list and watch each one light up on the grant.
Who approved it
The person at the top of the chain. That name cannot change as the grant is handed down.
What they approved
A fingerprint of the person's written decision. The text itself is not inside the grant.
Which agent may use it
The agent is identified by its own key.
Which tools
Named tools, or a family of tools such as "every payments tool".
Kinds of action
Some of: read, write, run, approve.
Which records or resources
Signed and narrowed as it is handed down, but not yet checked by any gateway.
Not yet checkedHow sensitive the data may be
Four levels: public, internal, confidential, restricted.
How many calls
A hard limit on the number of calls.
How much money
A spending limit in a stated currency.
Where it may connect
A list of allowed network destinations. Checked only by the HTTP gateway today.
How far it can be handed down
At most 4 hand-offs by default.
When it runs out
Interactive work: 15 minutes by default, 24 hours at most. Long-running jobs: 24 hours by default, 7 days at most, only when the person allowed a long run. Clocks may differ by up to a minute.
Proof it is genuine
A digital signature from your organisation's key.
A grant cannot set a rate limit today, so we do not list one.
One entry for every decision, yes or no.
The operations agent restarted a staging service.
The same agent tried to delete the production database.
The rule "never delete an instance" matched.
A coding agent tried to run its tests after its grant was withdrawn.
The call was refused and recorded.
Every decision is one of five, and the record says which.
Allowed
The call ran, inside the grant and your rules.
Stopped by your rule
A rule someone on your team wrote matched, so the call never ran.
Refused
The call was outside what was granted, so Torvant said no by design. For example: the grant had run out or been withdrawn, the signature did not check out, the tool was not in the grant, or the call would have gone over the spending limit.
Waiting for a person
The call needs a fresh human approval. Nothing runs until a person says yes.
Checked only in part
The call ran, but one check could not be made at full strength. It is never counted as allowed.
Red is not amber.
Red means a person's rule matched. Amber means the call was never within the grant. "Withdrawn" and "expired" are kinds of refused, not separate states.
A check that cannot run is a no.
When Torvant's own check cannot be reached, the call is refused, not waved through.
Two extra labels in a watch-only week.
Flagged for review: allowed, but marked for a person to look at. Would have been stopped: a rule matched, but nothing is blocked yet.
How anyone checks the record without trusting us.
Linked entries
Each entry carries a fingerprint of the entry before it. The first points back to the person's decision. Change one character anywhere and the links break.
Signatures
Your organisation's key signs each grant and, from time to time, the latest entry in the record. Checking needs only your public key.
Independent time
A time-stamping service can add an outside proof of when a signature was made. We have not tried this yet.
Without our software
A short checker, written only from the published specification and needing nothing from Torvant, confirms the links and the signatures.
Limits: the links alone cannot show entries removed from the end. The signatures cover that up to the latest one, and a copy kept elsewhere is needed if someone can delete both. A broken record is reported loudly by design, and there is no way to force it through.
Six things Torvant does today, each with its limit.
Signed grants that run out
An agent's authority ends on its own, with no key to rotate.
- How we know
- Every grant is digitally signed, and the signature is checked before anything else in it. Shared test cases agree across all three versions of the software.
- Limit
- 15 minutes by default for interactive work, 24 hours at most; long-running grants up to 7 days. If your identity provider ends a person's session, the grant still works until it runs out.
Hand-offs only narrow
A sub-agent can never get more than the agent that handed work to it.
- How we know
- A smaller grant is checked against the one it came from, when it is made and when it is used. A request to add a tool was refused in our test run.
- Limit
- 4 hand-offs by default. Only one of our gateways re-checks a handed-down grant against its source today.
No by default
Anything no rule allows is refused, so a missed case fails safe.
- How we know
- Every rulebook we ship starts from "refuse". The rules are plain matching, with no AI model deciding.
- Limit
- A rule that blocks one way of writing a shell command can miss another. For agents that run shell commands, use a list of what is allowed.
A record of every decision
Allowed and refused calls both leave an entry an auditor can check.
- How we know
- Each entry is linked to the one before, back to the person's decision. The latest entry is signed from time to time. A small checker with no Torvant code confirms it.
- Limit
- Any edit shows, but nothing stops an edit. Entries after the last signature are covered only by the links. Copy the signatures elsewhere.
Withdrawal that reaches every hand-off
Withdraw a person, an agent or one grant, and everything handed down under it stops.
- How we know
- In the built-in demo, the next call was refused 1 millisecond after the grant was withdrawn.
- Limit
- Gateways on other machines check every 5 seconds by default. If the central service cannot be reached, grants keep working until they run out; once the withdrawal list is too old, calls are recorded as checked only in part.
Watch-only week
See every tool call an agent makes, and what blocking would change, before you block anything.
- How we know
- Torvant sits between the agent and its tool server, records every call, flags tools whose names suggest they change something, and writes a one-page report.
- Limit
- Works only with MCP tool servers reached over HTTP. Nothing is blocked. Flags come from words in tool names, not from what the tools do.
Honest status, part by part.
"Shipped" means built, tested and in our hardened tier. Nothing is in production use yet: there are no external deployments. No AI model takes part in any decision.
Local, on a developer's machine
One step sets up keys, a rulebook, a 24-hour grant, the Claude Code check and a small background service. It starts in watch mode; you switch on blocking when ready.
Self-hosted, in your network
The agent sits on a network whose only way out is through Torvant. Torvant holds only your public key. The record is written to storage you own. This containment holds on Linux only.
Kubernetes
Setup files and an operator.
Hosted by Torvant
Not available.
What you need
Node.js 22 or later. Docker with Compose for the self-hosted setup. Claude Code for the coding-agent path; confirm the setup, because if Claude Code cannot find Torvant's check, it lets calls through. Runs on Linux. macOS and Windows not yet tested.
Torvant does not make you compliant with anything.
It gives you records your auditor can check against these frameworks. Your auditor decides what they are worth. Evidence packs: prototype
MAS SAFRSingapore · Safeguards for Agentic Finance at Runtime
What it asks for
A checkpoint between every agent decision and the action. The agent's identity is confirmed, the action is checked against the firm's rules and the agent's authority before it runs, and every decision, refusals included, is written to a tamper-evident audit log from which what happened can be rebuilt without relying on the agent's own account.
What answers it
Records your auditor can check against SAFR's four runtime components, in line with SAFR. The signed grant shows who the agent is and what authority it holds. The check runs before every call. The record is written by Torvant, not by the agent, and names the rules applied and the reason. SAFR's four outcomes (Auto-Execute, Deny, Escalate and Observe) map to allowed, stopped or refused, waiting for a person, and allowed but flagged.
Gaps the map names: the time taken at each stage of the check, rate limits, and approving a smaller amount than was asked. SAFR is a white paper MAS published with industry in July 2026. It says it is not regulatory guidance or supervisory expectations.
Reserve Bank of IndiaThree texts: draft model risk guidance (2026, not yet binding), the FREE-AI committee report (2025, advisory), and the 2024 cyber-resilience directions for non-bank payment operators (binding)
What it asks for
A human in command, a kill switch, traceability, and the firm's own independent check of any vendor's claims. For payment operators, audit logs that show who acted, what they did and with what details, kept for at least 5 years.
What answers it
Records your auditor can check against these texts. Every entry traces to a named person. Withdrawing a grant is the kill switch, and it is recorded. Your own team can check the record with only your public key.
The record holds a fingerprint of the details sent, not the details, so keep the request alongside it.
EU AI ActEuropean Union
What it asks for
Automatic logs of what an AI system does, and effective human oversight.
What answers it
The record covers every attempted tool call, allowed and refused, linked so edits show. Every grant traces to one recorded human decision, hand-offs only narrow, and a person can withdraw authority at any time.
ISO/IEC 42001AI management systems
What it asks for
Defined roles and responsibilities, documented AI risk treatment, human oversight, monitoring, and internal audit.
What answers it
Records your auditor can check against its requirements. A named person on every grant, approval records, rules as documented controls, and record checks your auditors run themselves.
The mapping itself says it is evidence, not certification.
DORAEU Digital Operational Resilience Act
What it asks for
A financial firm keeps a register of its technology suppliers, and its contracts give it audit access and a clean exit.
What answers it
The evidence pack fills in Torvant's own entry for that register and maps the contract terms. You hold the full record, can check it without us, and it stays checkable after you leave.
SOC 2Your own controls, not ours
What it asks for
Least-privilege access, removing access when it should end, monitoring, and ongoing checks.
What answers it
Records your auditor can check against those controls. Agents get short-lived grants instead of standing credentials, withdrawals are recorded, and every decision is recorded.
Torvant itself has no SOC 2 report.
GDPRRecords of processing, Article 30
What it asks for
A record of each processing activity: who, for what purpose, and for how long it is kept.
What answers it
The evidence pack drafts that record for agent tool calls, from the people and agents on your grants. The record stores fingerprints of what agents sent, not the data itself.
Said plainly, before you find it.
Not audited.
The external cryptographic audit is funded and pending. Nothing may be called audited until it lands. An internal review has already been done ahead of it.
No certifications.
No SOC 2, ISO 27001 or other certification report exists. The framework maps above are mappings, not attestations.
Red-team results: not done.
The first phase of the plan is complete.
Most of the product is prototype.
The hosted service, partner SDKs, Slack approvals, Postgres storage, security-monitoring exports, evidence packs and more are built end to end to prove the shape. Not production-hardened; no external deployments yet.
Known gaps in the hardened core.
- Hand-offs are re-checked in only one of our gateways.
- Limits on which resources a call may touch are signed but not yet checked.
- Limits on network destinations are checked only by the HTTP gateway.
- Checking on the tool-server side is not on by default.
- Hiding sensitive data in streamed responses is not done.
The coding-agent check is the weakest layer.
It runs inside the same boundary as the agent. The strong boundary is an isolated development container with the self-hosted setup around it.
Apps and platforms.
Claude Code is the only coding app the one-step setup supports. Runs on Linux. macOS and Windows not yet tested. Containment in the self-hosted setup holds on Linux only.
Source licence: open core.
Apache-2.0 for the protocol, core libraries, command-line tool and SDKs. BSL 1.1 for the gateways, rule engine and record store. A commercial licence for the managed service and evidence packs. Terms are under review by counsel.
Not public yet.
The code is not published and the packages are not on the public registry. Both wait on review by counsel. The specification is frozen at version 0.2.
The threats we planned for, and what is left.
Forged grants
Every grant is signed, and Torvant accepts only your organisation's known key.
Remaining: lowA fake issuer
Gateways accept only listed issuers. A full certificate chain for your organisation is planned.
Medium until thenEdits to the record
Checks walk the whole record and fail loudly. Signatures can be copied elsewhere.
Prompt injection creating authority
Injected text cannot sign anything. A grant can only come from a person's recorded decision that passes your rules.
Winding the clock back
Clocks may differ by a minute at most, and entry numbers only go up.
An agent pretending to be another
An agent's identity is its own key. Holding the key is the identity.
Someone pretending to be the approver
This depends on the strength of your identity provider.
Remaining: medium"The AI did it"
Every entry ties the grant, the decision and the person together. Refusals are recorded too.
Many calls at once to beat a limit
Each grant's counters are updated one at a time, so parallel calls cannot slip past a limit.
Accepted gaps
No guarantee if someone routes around Torvant (the answer is the contained network setup). Hiding data in streamed responses is not done. One writer per record limits scale. No formal cryptography audit yet.
Key handling
- Private keys are saved so only the owner's account can read them.
- Torvant's gateway holds only your public key. The private key stays with whoever issues grants.
- The rulebook for coding agents stops the agent reading or changing its own keys, rules, check, grant and record. A determined shell command can sidestep some of these, so treat them as speed bumps.
- Keys held in a cloud key service (AWS, Google Cloud or Azure), which signs there and never releases the key: prototype, tested against stand-ins of the three services and not yet against a live account.
What leaves your network, and what does not
- In the self-hosted setup, nothing leaves your network.
- The record stores a fingerprint of what the agent sent, never the content.
- A grant carries a fingerprint of the person's decision, not its text.
- In a watch-only week, sign-in details for your tool server go only to that server. Torvant never uses them to decide who is calling.
- The watch report page loads Google Fonts and nothing else, and uses the computer's own fonts when offline.
- No AI model takes part in any decision.
The defaults, counted.
How long an interactive grant lasts by default
The longest an interactive grant can last
The longest a long-running grant can last
Hand-offs allowed by default
From withdrawing a grant to the next call refused, in the built-in demo on one machine, without network time
How often a gateway on another machine checks for withdrawals, by default
The one-step setup supports Claude Code today
Pieces of your tool data stored in the record. Fingerprints only.
No customer, deployment or uptime numbers: there are no external deployments yet.
Questions security teams ask first.
Does this replace our identity provider?
No. Your identity provider proves who the person is. The grant carries what that person approved for one agent, for a limited time.
What happens if Torvant's check is down?
Calls are refused, not waved through. A check that cannot be reached is a refusal, never an opening. We have seen this happen in our own test run.
What if Torvant's central service cannot be reached?
Grants that have not run out keep working, and no new grants are issued. Once the withdrawal list is too old, those calls are recorded as checked only in part, not as allowed.
Can a prompt-injected agent give itself more access?
It cannot sign a grant, and a handed-down grant can only be smaller than the one it came from. It can still misuse what it was given, inside the limits.
Can our auditor check the record without your software?
Yes. A short checker that needs nothing from Torvant does it, using only your public key, never a private key.
Do you store our tool data?
The record holds a fingerprint of what was sent, not the content. In the self-hosted setup nothing leaves your network.
Can we try it without blocking anything?
Yes. The watch-only week lets every call through and records it, and its report shows what blocking would have changed. The coding-agent setup starts in the same watch mode.
Has the cryptography been audited?
No. An external audit is funded and pending. An internal review has already been done ahead of it.
Does Torvant make us compliant?
No. It gives you records your auditor can check against the frameworks above.
See it on your own agent.
A 30-minute call. We watch one of your agents, block nothing, and show you what your rules would have stopped.