Integration Overview

Intercept is designed to sit between an agent's decision and onchain execution. There are two planned ways to put it there. They share the same policy file, the same evaluation pipeline and the same decision object. They differ in one property that matters more than anything else on this page: whether the agent can move funds without Intercept.

Neither path is available today. The SDK and API described in this section are illustrative and unpublished.

Advisory integration

In advisory mode, the agent holds its own signing key. Before sending a transaction, it calls evaluate(), reads the decision, and is expected to send only approved transactions.

• Intercept simulates the transaction, applies risk and security checks, and returns approved, blocked or requires_approval with reasons.
• The agent signs and sends with its own key.
• Nothing onchain requires Intercept's participation.

Advisory mode is useful for development, for shadow-testing a policy against live behavior, and for agents whose operators trust the agent code but want independent pre-trade checks. It is fast to adopt because no funds move.

Its limit is fundamental. A compromised or misbehaving agent can skip the call or ignore a block. If an attacker gains control of the agent through prompt injection or a dependency compromise, it holds a key that can move funds, and Intercept cannot stop it. Advisory mode reduces mistakes; it does not contain an adversary.

Enforced integration

In enforced mode, funds sit in a policy-controlled account, such as a program-owned vault or a multisig-style smart account, where Intercept's policy signer is a required co-signer. The agent can propose transactions but cannot complete them alone.

• The agent builds a transaction and calls evaluate().
• If the decision is approved, execute() asks Intercept to co-sign. Intercept is designed to re-check that the transaction being signed is byte-for-byte the one it evaluated.
• If the decision is blocked, Intercept does not sign, and the transaction cannot execute.
• If the decision is requires_approval, an owner or operator must approve before Intercept signs.

Blocking only works if the integration is enforced. That is the guarantee enforced mode is designed to provide, and the reason it exists. It is planned, not built.

Enforced mode also has costs:

• Liveness dependency. If Intercept cannot sign, the agent cannot transact. The design includes guardian-controlled recovery so that owners are never locked out of their funds, but that path is deliberately slower than normal execution.
• Migration. Funds must move into the policy-controlled account.
• Latency. Co-signing adds a round trip after evaluation.
• Trust in the signer. Intercept can refuse to sign. The account design is intended to ensure Intercept alone can never move funds; it can only withhold a required signature.

Choosing a path

A common path is designed to be: start in advisory mode, run the policy in shadow against real behavior until its false-block rate is acceptable, then move funds into an enforced account using the same policy file with "mode": "enforced".

Integration shape

import { Intercept } from "@intercept/sdk"; // illustrative — not yet published

const intercept = new Intercept({
  apiKey: process.env.INTERCEPT_API_KEY,
  policy: "./intercept.policy.json",
  cluster: "mainnet-beta",
});

const result = await intercept.evaluate(transaction, {
  agentId: "agent_7f3c",
  intent: "Swap 1,200 USDC to SOL on Jupiter",
});

if (result.decision === "approved") {
  const signature = await intercept.execute(result); // co-signs in enforced mode
} else if (result.decision === "requires_approval") {
  await intercept.requestApproval(result.evaluationId);
}

The code is the same in both modes. In advisory mode, execute() is designed to submit the transaction the agent already signed; in enforced mode, it adds Intercept's co-signature. The mode comes from the policy file, so the integration does not change when you switch.

Next steps

• SDK for the full illustrative method surface.
• API Reference for direct HTTP use.
• Configuration for every policy field.
• Error Handling for reason codes and fail-closed behavior.