Roadmap

This roadmap describes the order in which Intercept is planned to be built and what each phase must demonstrate before the next begins. It has no dates on purpose. Phases end when their exit criteria are met, not on a calendar.

Summary

Nothing is publicly implemented today. Every page in these docs describes design and specification work.

Phase 0: Research and specification

Status: current.

Phase 0 defines what Intercept is and how its parts fit together before any of it is built.

Goals

• Specify the policy file schema, the decision object and the reason-code taxonomy (RISK_*, SEC_*, NET_*, SYS_*).
• Define the transaction lifecycle: proposal, simulation, risk evaluation, security verification and decision.
• Draft the illustrative SDK and API surfaces and collect feedback from agent builders.
• Study account designs for enforced mode, such as program-owned vaults and multisig-style smart accounts, and their recovery paths.
• Catalogue agent failure modes and onchain attack patterns the engines must handle.

Exit criteria

• A versioned specification for the policy schema, decision object and reason codes.
• A written threat model covering compromised agents, prompt injection, malicious programs and Intercept's own failure modes.
• A chosen account design for enforced mode, with documented trade-offs.
• Documentation, including this site, that matches the specification.

Phase 1: Risk engine and advisory SDK

Status: planned.

Phase 1 delivers the first usable software: evaluation of transactions against risk limits, in advisory mode.

Goals

• Build the risk engine: transaction size, daily spend, position size, leverage, drawdown, slippage and liquidity checks.
• Integrate simulateTransaction so that every decision is based on simulated balance changes, not the agent's description.
• Publish a first version of @intercept/sdk with evaluate, policies.validate and policies.publish.
• Support shadow mode, in which decisions are logged but not acted on, for tuning policies against real behavior.

Exit criteria

• The risk engine produces correct decisions on a published test suite of transactions, including adversarial cases.
• Evaluation latency is measured and published, with methodology.
• External developers have run the SDK in advisory or shadow mode and their feedback is reflected in the interface.
• Documentation clearly states that advisory mode can be bypassed by a compromised agent.

Phase 2: Transaction firewall and enforced execution

Status: planned.

Phase 2 makes blocks binding. Blocking only works if the integration is enforced, and this is the phase that is designed to make enforcement possible.

Goals

• Build the security engine: protocol allowlists, blocked addresses, simulation requirements, unlimited-approval and authority-change detection, and intent-versus-effect checks for suspected prompt injection.
• Deploy the policy-controlled account design, with Intercept's policy signer as a required co-signer.
• Add execute, requestApproval, pause, resume, circuit breakers and webhooks.
• Implement guardian-controlled recovery so that owners can retrieve funds if Intercept is unavailable.

Exit criteria

• Onchain programs have completed independent security audits, with reports published. No audit has taken place yet.
• Recovery has been tested end to end, including the case where Intercept is permanently unreachable.
• Co-signing is shown to sign only transactions identical to those evaluated.
• Availability and latency targets are defined and measured under load.

Phase 3: Intercept Network

Status: concept.

Phase 3 extends protection from a single agent to every connected agent. See Network Overview.

Goals

• Design and run the Threat Registry with pending, verified, expired and disputed states.
• Define the role of security operators, including signed reports and reputation.
• Feed verified signals into the security engine as NET_FLAGGED_ADDRESS and NET_FLAGGED_PROGRAM.

Exit criteria

• Answers to the open questions on governance, incentives and operator selection, published before launch.
• Demonstrated resistance to poisoning and griefing in adversarial testing. See Collective Defense.
• A privacy review of what agents reveal when consuming or contributing signals.