MCP Guardian Network

Why this exists

Attack patterns against AI agents repeat. A prompt injection that hits one company's agent will be tried against others. SQL injection patterns, data exfiltration via tool calls, and jailbreak techniques all follow detectable signatures.

The Guardian Network is a federated, opt-in system that lets ABS instances share anonymized threat signals. When your instance detects a novel attack pattern, participating peers receive the signal within minutes — before the same pattern hits them.

Privacy design

No raw data is ever shared. The network operates entirely on SHA256 pattern hashes:

• What is shared: SHA256(tool_name + pattern_fingerprint) — a one-way hash of the threat pattern
• What is never shared: Tool input data, agent IDs, tenant names, business logic
• Tenant identity: Your participation is identified only by SHA256(tenant_id + rotating_salt) — one-way and unrecoverable

Participation requires explicit double opt-in: you must enable both contribute (share signals) and receive (accept signals) independently.

Enable participation

POST /v1/network/opt-in
Authorization: Bearer {your-api-key}

{
  "contribute": true,
  "receive": true
}

You can participate in receive-only mode if you want threat intelligence without contributing:

{ "contribute": false, "receive": true }

How signals flow

Tenant A detects: exec_cmd called with SQL injection pattern
  ↓
Tenant A publishes signal: { tool_name_hash, pattern_hash, severity: "HIGH", expires_in: "7d" }
  ↓
Guardian Network stores signal (anonymized)
  ↓
Tenant B (opted in to receive) fetches signals on next /v1/authorize
  ↓
Tenant B's risk score increases by +30 when exec_cmd matches the pattern hash

Risk score contribution

Received network signals raise the risk_score of matching requests. The boost depends on signal severity:

The boosted risk score feeds directly into the WASM policy engine. If your policy denies requests above risk 70, and a request arrives that would normally score 50 but receives a +30 boost from a network signal, it will be denied.

Publish a signal manually

If your security team identifies a novel attack pattern not yet detected automatically:

POST /v1/network/signal
Authorization: Bearer {your-api-key}

{
  "tool_name": "db_query",
  "pattern": "SELECT.*FROM.*WHERE.*1=1",
  "severity": "HIGH",
  "description": "SQL injection via db_query tool"
}

ABS hashes the pattern before publishing — the raw content never leaves your instance.

View received signals

GET /v1/network/signals

{
  "signals": [
    {
      "id": "sig_01JN...",
      "tool_name_hash": "a3f8c2...",
      "pattern_hash": "b9e1d4...",
      "severity": "HIGH",
      "received_at": "2026-02-21T08:00:00Z",
      "expires_at": "2026-02-28T08:00:00Z",
      "source": "network"
    }
  ],
  "total": 1,
  "your_contribution": 3
}

Invariants

• GN-I1: Opt-in is always explicit — no data is ever shared without both contribute: true and an active opt-in record
• GN-I2: Pattern hashes are one-way — raw inputs cannot be recovered from the network
• GN-I3: All signals expire after 7 days — no indefinite accumulation
• GN-I4: Network sync failures never block local authorization — the network is advisory only
• GN-I5: Tenant identity hash uses a rotating salt, preventing long-term tracking