The company console for AI‑native teams.

No. Threshold sits between your agents and the systems they touch. Your engineers keep using Cursor, Claude Code, Codex, ChatGPT, whatever they already prefer. The change is invisible to them and visible to you.

Most safety tools watch what the agent does. We decide what it gets to do. Detection layers run after the action and tell you what just happened. Threshold runs before the action and decides whether it happens at all.

A clever input cannot become an authorized action, because the policy runs against the boundary label, not against the model's interpretation of the request.

MCP gateways and Threshold are doing related work at different layers. Gateways focus on identity, access control, and audit at the protocol level: who is allowed to call which MCP tool. Threshold focuses on the architectural separation between an agent's intent and its action: should this call happen at all, given where the instruction came from.

The practical difference shows up in three places. First, prompt injection. Gateways rely on threat detectors that classify suspicious requests. Threshold runs policy against boundary-tagged input lineage, so untrusted text cannot authorize a sensitive action.

Second, sensitive data. Gateways broker the call, but the data still passes through the model's context. Threshold runs sealed execution, so the agent reasons on schema and the underlying records are never read by the model.

Third, audit. Gateways log requests. Threshold writes signed, externally-anchored receipts of every decision, including refusals, as audit-grade evidence.

You can run Threshold alongside an MCP gateway. They occupy different layers and solve different problems.

No. Threshold attaches to your workflow. You don't migrate to ours. Existing agents (Claude Code, Cursor, custom harnesses, anything MCP-compatible) keep working exactly as they do today. The only change is that their tool calls flow through Threshold instead of going directly to GitHub, AWS, or wherever else.

You can self-host Threshold inside your own VPC, or run it as a managed service. In either case, raw prompt data, customer records, and source content stay on infrastructure you control. We only retain the metadata required for cost attribution and the signed audit log.

Sealed-execution workflows go further. The agent never sees the underlying data at all. Threshold operates against the records inside a trusted enclave and returns only the result.

Most tools detect it probabilistically. We refuse it structurally. Every input entering your agent's context (a customer ticket, an email, a web page, a vendor document) gets tagged at the boundary as trusted or untrusted, and that label travels with the data.

When the agent decides to take an action, the policy engine checks the lineage of the request: where did this instruction come from? An untrusted source cannot authorize a transfer, a deploy, or an irreversible action, no matter how convincingly it's phrased. The check is a typed predicate that fails the same way every time.

A capable engineering team could build any one of Threshold's properties: boundary tagging, capability tokens, signed audit chains, sealed execution. What's hard to build is the four together, fast enough to live in the request path, grounded in cryptographic primitives most security teams do not have on staff.

Peer companies have spent eighteen months and seven figures on systems that do roughly thirty percent of what Threshold does. The build-versus-buy math gets one-sided quickly once the cryptographic foundations are accounted for.

Because the guarantees this category needs are not bolt-on features. They are architectural choices made at the foundation. Signed provenance, capability-based authorization, sealed execution, tamper-evident audit chains: these are cryptographic primitives, not security UX. Inversed has been building on them for years across Worldcoin, Scroll, and the broader applied cryptography ecosystem. The console is what you see. The cryptography is the part that makes the console worth trusting.

Threshold isn't a SaaS you deploy alone. We work with you to integrate it into the workflows you already run — the connectors your team uses, the policies your security team has written, the agents your engineers already prefer.

Most teams start with a focused pilot on one high-value workflow, then expand as it earns trust. The first integration is collaborative; the next ten are configuration.

The T8 Engine is a stateless low-latency proxy. It intercepts agent traffic, resolves credentials at the edge, and forwards the call — typically in single-digit milliseconds. The agent's process never holds the credential; Threshold does. No changes to agent code are required. Connects via HTTPS, MITM, or an HTTP-proxy path depending on your runtime.

Policies run inside V8 isolated-vm sandboxes — no Node.js globals, no filesystem access, no network access. Each policy script has access only to the calling agent ID, the tool being invoked, and the arguments. Evaluations execute in resource-bounded VMs, typically under a millisecond. If the policy runner is unhealthy, the system falls back to a configurable per-workflow default (allow or deny).

Every decision and every action is appended to a Merkle-tree log structured after RFC 9162 (Certificate Transparency). Inclusion can be proven in O(log n). Signed checkpoints are pushed to external anchors of your choice — AWS S3 with Object Lock, Git, public blockchains, or signed emails. This makes silent deletion or modification detectable by external verifiers, not just by us.

Threshold uses the x402 protocol for gasless USDC transfers across EVM networks. The agent calls a RemoteProvider interface that forwards the payment request to a process-isolated signer running in a separate VM. The signer holds the key; the agent only sees the result. Spending budgets — single-transaction caps, daily limits, per-connection ceilings — are enforced before the signer ever sees the request.