Technical brief · seven minute read

What Interpose checks, records, and proves.

Interpose installs as a native hook in the agent harness, Claude Code today, and checks every tool call in the agent's own process, before it runs, with no model in the decision. This page is written for the person who has to answer for it in production: what you can prove, what you can control, and what you can audit.

Three questions Scope and limits The hook model The four checks What you get The policy The signed trail Model escalation Coverage and deployment

Three questions a security architect asks first.

Why not Claude Code's own hooks?: Interpose builds on them. Native hooks are the strongest free primitive and the floor Interpose stands on. What a raw hook does 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.
Why not a gateway or proxy?: A proxy sees traffic, not intent. It sits outside the agent, so it never sees which tool was called, which file was read, or whether the action matched the task the developer typed. Put a model in the block path and it inherits the same prompt injection surface as the agent it is judging. In process, Interpose has neither problem.
Why in process and deterministic?: The block decision is a rule, not a judgment. Hard rules and scope give the same answer to the same input every time, with no model and no network hop on the block path. The baseline is observational and never blocks. The limits of that model are stated in the next section.

Scope and limits, stated plainly.

What it is: A guardrail with a verifiable record, not a sandbox. Enforcement happens where Claude Code asks to run a tool, through its hook, on a cooperative agent doing normal work. It is not adversarial containment.
The trail: Tamper evident, not tamper proof. The trail is hash chained and signed, so tampering or a deleted entry is detectable and provable. The value is proof, not prevention of the edit.
Same host ceiling: Interpose runs on the same machine as the agent, so a process determined to route around it on that host can. That is where the signed trail is the backstop: you can still detect and prove what happened. For prevention against a hostile process, pair Interpose with OS and network isolation.
Detection: The baseline is observational. It surfaces anomalies in reports as a signal to investigate, not as an enforcement control.

The hook model. Three checkpoints.

Interpose registers as a native Claude Code hook and intercepts the agent at three points. MCP tool calls pass the same pre-execution checkpoint as any other tool call.

pre-prompt (UserPromptSubmit)

The stated task is captured. Everything the agent does next is judged against it.

pre-execution (PreToolUse)

Every tool call is checked before it runs. This is where blocks happen, so the side effect never lands.

post-execution (PostToolUse)

Outcomes are recorded and compared against the baseline for the role.

The four checks, in order.

1 · Hard rules: Credentials, keys, cloud configs, and system directories are denied from day one. The floor ships with the policy and is never released by a developer.
2 · Role scope: Each agent runs under a role with a scope. Actions outside it are logged in alert mode and denied in block mode.
3 · Task match: Each action is measured against the task the developer typed at the start of the session. Drift from it is the signal a static rule cannot see.
4 · Baseline: Deviation from what this role normally does is surfaced for a person to look at. It flags for investigation. It does not block.

What the security owner gets.

Prevent

Policy enforced before execution.

Every tool call is checked against your policy and allowed or denied before it runs, not flagged afterward. Out of the box the policy protects credential stores, private keys, cloud configs, and system directories. A network allowlist gates tool level requests.

Detect

A baseline per agent.

Interpose learns each agent's normal pattern of work and surfaces deviations in reports, for the novel behavior a fixed list will not catch.

Prove

A signed record of every tool call.

Every decision, allowed or denied, is appended to a per project, hash chained, Ed25519 signed trail anchored by a signed manifest. Alter or delete an entry and verification fails.

Assess

See the blast radius first.

interpose scan lists the files an agent could reach, scored by how sensitive each looks by path pattern. Read only. Tighten policy before it matters.

The policy.

init writes a starter policy, and Interpose recommends tightening from the actions your developers approve and deny. Every control has an alert setting and a block setting, so the security team decides which risks it watches and which it stops. Policy is set centrally and cannot be edited from a developer machine.

# .interpose.yaml
policy:
  allow:
    actions: [file_read, file_write, tool_invocation, network_request, command_exec]
    targets:            # logged if outside, denied in block mode
      - "src/**"
      - "test/**"
    networkHosts:       # network_request denied unless listed
      - "api.anthropic.com"
      - "github.com"
  forbid:
    targets:            # hard deny, never released
      - "secrets/**"
      - "/etc/**"
enforcement:
  restrictAfter: 3      # restrict after this many violations
  quarantineAfter: 5    # quarantine after this many

scopeBoundarydefault advisory: enforce denies out of scope file reads and writes. Advisory logs a scope violation but still runs.
egressScreendefault off: Screens shell network commands against the allowlist. Alert first: it logs interpreter and obfuscated egress rather than blocking it.
askOnDestructivedefault on: Routes a curated set of irreversible destructive shell commands to Claude Code's confirmation prompt.
unknownToolsdefault warn: Disposition for unrecognized tool names. warn allows and logs. deny blocks, with an allowlist escape hatch.

The signed audit trail. Prove what ran.

Verify: interpose --verify-audit re-walks the whole hash chain and checks every Ed25519 signature, then returns a single VALID or INVALID verdict you can hand to a reviewer.
Read: interpose --show-audit prints the signed entries behind that verdict, newest first. Paths and commands are redacted to shape by default. A deny names the file that was reached, not the secret it would expose.
Recover: On a soft flag the developer releases a blocked action in one click. A restricted or quarantined agent is restored with interpose release from a separate terminal. Interpose reconstructs why the stop fired and proposes a narrow, expiring exception for a person to approve. Nothing is applied on its own.

Model escalation. Optional, in your boundary.

When: Only genuinely ambiguous cases. Hard rules are always decided by the deterministic core. The model never sits on the block path for anything you have already made a rule.
Where: Out of process, on an endpoint you bring. You choose the model. It runs on your infrastructure, never on Tuent's.
Direction: Tightening only. An escalation can raise scrutiny or confirm a stop. It cannot loosen a deny, and credentials never escalate.
Fallback: If the endpoint is unreachable, the deterministic decision stands. The core does not wait on a model to keep the agent safe.

Coverage, deployment, and present state.

Agents: Claude Code today, through a native hook. That is the only live integration. Support for additional harnesses is on the roadmap.
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.
Runtime cost: Under a millisecond for the decision itself, with no network hop on the block path. Entries sync to the console afterward. Nothing for your developers to wait on.
Boundary: On your machines, under your keys. Nothing about your agents, code, or actions reaches Tuent, including on model escalation.
Deployment: Deployed by Tuent during the pilot. Interpose is not self serve. Evaluation runs as a three week pilot, scoped with you, in your own boundary.
Standing: Listed on the CSA AARM Builders Registry. AARM standing is Aligned, self declared. The registry listing reflects builder alignment.
State: Current release. The signed audit trail and the false positive recovery are live end to end.

This page reflects the present shipped state and moves as the product ships. Figures elsewhere on this site are illustrative unless marked otherwise.

Scope it against your environment.

Thirty minutes to map where your agents run and what a three week pilot would prove. Week one runs in transparent mode, so nothing is blocked while you watch.

Scope a pilot Back to docs

Questions on anything above? james@tuent.ai or charlie@tuent.ai. A founder answers.