DEV Community: razashariff

We Sent a Cryptographically-Signed AI Agent Payment Over 868 MHz Radio. No Internet. No Cloud. Just Trust.

razashariff — Wed, 06 May 2026 13:13:08 +0000

We Sent a Cryptographically-Signed AI Agent Payment Over 868 MHz Radio. No Internet. No Cloud. Just Trust.

By Raza Sharif, CEO/Founder | contact@agentsign.dev

Airplane mode. Two Heltec LoRa boards. A signed MCPS frame crossed 868 MHz radio and settled in under 2 seconds.

No internet. No Lightning node. No cloud infrastructure. No blockchain.

Just a cryptographic signature, a nonce, and a trust level — travelling at the speed of radio.

This is what happened, how we built it, and why it matters for every AI agent you are shipping right now.

The Problem Nobody Is Talking About

MCP (Model Context Protocol) has 97 million SDK downloads. Over 13,000 servers are publicly listed. It is the fastest-growing AI integration standard in history.

It shipped with no message signing.

Not "limited signing." Not "optional signing." Zero. Any process on the network can forge a tool call. Any captured frame can be replayed indefinitely. A server has no cryptographic way to verify the agent calling it is who it claims to be.

Here is what a standard MCP tool call looks like on the wire today:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "transfer",
    "arguments": { "to": "agent_b", "amount": 1000 }
  }
}

No signature. No nonce. No identity. If you capture that frame, you can replay it forever.

OWASP confirmed prompt injection, tool poisoning, and authentication bypass as the top three MCP threats — all exploitable on standard implementations today. Gartner reported a 1,700% increase in agent security enquiries in 2026. The industry is waking up to a problem that was baked in from day one.

We built the security model for secure MCP use.

MCPS — Model Context Protocol Security

MCPS is an IETF internet draft that adds cryptographic signing to every MCP message. ECDSA P-256. Per-message nonces. Timestamp validation. L0–L4 trust levels. Drop-in compatible with the existing MCP spec.

Every MCPS frame looks like this:

MCPS:1:<agentHash>:<serverHash>:<amountHex>:<nonce>:<timestamp>:<P256sig>:<memo>

Example:
MCPS:1:a3f8c2d1:b7e94a20:0x03E8:a1b2c3d4:1746543210:MEQCIHx9...==:transfer
       ↑version ↑agent    ↑server ↑amount  ↑nonce    ↑unix ts  ↑sig44     ↑memo

The server verifies the signature before executing anything. The nonce is stored and rejected if seen again. The trust level gates what the agent is permitted to do.

Seven npm packages. A Java Keycloak mapper. Python and Go implementations. The x-agent-trust extension is now on the official OpenAPI extension registry — PR #67, merged April 2026, approved by Microsoft and the OpenAPI TDC.

That is the protocol. Now here is what we did with it.

The Build: MCPS Over 868 MHz LoRa Radio

We wanted to know: how transport-agnostic is MCPS really?

So we stripped away every assumption. No TCP/IP. No Wi-Fi. No internet. We put the phone into airplane mode and routed an MCPS payment frame across a 868 MHz LoRa radio mesh.

Hardware

Two Heltec WiFi LoRa 32 V3 boards running Meshtastic firmware:

c758 — TX board. Paired with an iPhone via BLE. Receives MCPS frames from our iOS app and transmits over 868 MHz LoRa.
84cc — RX board. Paired with a Mac via BLE. Receives incoming LoRa frames and forwards to the lnode-mesh backend.

Architecture

┌─────────────────────────────────────────────────────────┐
│  iPhone (Airplane Mode)                                 │
│  iOS App — signs MCPS frame — sends via BLE             │
└────────────────────────┬────────────────────────────────┘
                         │ BLE
                         ▼
┌─────────────────────────────────────────────────────────┐
│  Heltec c758 — TX Board                                 │
│  Transmits over 868 MHz LoRa                            │
└────────────────────────┬────────────────────────────────┘
                         │ 868 MHz LoRa (radio)
                         ▼
┌─────────────────────────────────────────────────────────┐
│  Heltec 84cc — RX Board                                 │
│  Receives over 868 MHz LoRa                             │
└────────────────────────┬────────────────────────────────┘
                         │ BLE
                         ▼
┌─────────────────────────────────────────────────────────┐
│  Mac — ble-listener.py                                  │
│  Meshtastic protobuf decode → POST /radio/receive       │
└────────────────────────┬────────────────────────────────┘
                         │ HTTP localhost
                         ▼
┌─────────────────────────────────────────────────────────┐
│  lnode-mesh.js — Node.js backend                        │
│  Verify MCPS sig → check nonce → update balances        │
│  SETTLED ✓                                              │
└─────────────────────────────────────────────────────────┘

Zero internet in the chain. Phone in airplane mode throughout.

The iOS App

The app builds a valid MCPS frame, signs it with ECDSA P-256, and sends it to the c758 board via BLE using the Meshtastic TORADIO characteristic. The key part was getting the Meshtastic 2.x protobuf encoding right — specifically FIXED32 wire type for the broadcast destination address (0xFFFFFFFF) and the correct field numbers for ToRadio.

// MeshtasticBLE.swift — encode broadcast destination correctly
private func encodeFixed32(fieldNumber: Int, value: UInt32) -> Data {
    var data = Data()
    data.append(UInt8((fieldNumber << 3) | 5)) // wire type 5 = 32-bit fixed
    data.append(UInt8(value & 0xFF))
    data.append(UInt8((value >> 8) & 0xFF))
    data.append(UInt8((value >> 16) & 0xFF))
    data.append(UInt8((value >> 24) & 0xFF))
    return data
}

The BLE Listener

ble-listener.py runs on the Mac, connects to the 84cc board via BLE, decodes the Meshtastic protobuf FromRadio stream, extracts text messages, and POSTs any MCPS frame to the settlement backend.

# ble-listener.py — detect and forward MCPS frames
if text.startswith("MCPS:"):
    result = post_to_backend(text, rssi=pkt.rx_rssi, snr=pkt.rx_snr)
    verdict = result.get("verdict", "?")
    # → SETTLED ✓

The Settlement Backend

lnode-mesh.js receives the frame, verifies the ECDSA signature, checks the nonce against a replay store, validates the trust level, and updates agent balances. It is the same MCPS settlement logic that runs in our cloud stack — unmodified — now running over radio.

The Moment It Worked

  ╔══════════════════════════════════════════════╗
  ║  MCPS PAYMENT RECEIVED OVER 868 MHz RADIO    ║
  ╠══════════════════════════════════════════════╣
  ║  Frame: MCPS:1:a3f8c2:b7e94a:0x03E8:a1b2..   ║
  ║  RSSI:  -7 dBm                               ║
  ║  SNR:   6.5 dB                               ║
  ╠══════════════════════════════════════════════╣
  ║  Verdict: SETTLED ✓                          ║
  ║  agent_a: 9000 sats                          ║
  ║  agent_b: 11000 sats                         ║
  ╚══════════════════════════════════════════════╝

Phone in airplane mode. No Wi-Fi. No mobile data. No internet anywhere in the chain.

RSSI -7 dBm. SNR 6.5 dB. Clean signal. Clean settlement.

First MCPS-signed agent transaction over radio. Done.

Why This Matters Beyond the Demo

We are not trying to build Stripe over LoRa. That is not the point.

The point is this: MCPS is transport-agnostic. The signing, the nonce, the trust level — they live in the frame, not in the network. HTTP, WebSocket, stdio, gRPC, BLE, 868 MHz radio — it does not matter. The trust travels with the data.

That has real consequences:

1. Disconnected environments
Agents operating in disaster zones, remote industrial sites, or air-gapped networks can still execute cryptographically-attributed transactions. When connectivity returns, settlement syncs. The signed log is the audit trail.

2. Incentivised mesh routing
Every relay hop can earn a signed micro-credit. Pay-per-forward with cryptographic receipt. No internet required for accounting — only for final settlement.

3. IoT and sensor data markets
Remote sensors publish data over mesh. Agents subscribe and pay. Deferred settlement when they reconnect. Metered access with a tamper-proof ledger.

4. The real insight for cloud deployments
If MCPS works on a 250 bps radio link in airplane mode, it works in your Kubernetes cluster. It works in your CI pipeline. It works in your agentic commerce stack. If the most constrained transport you can imagine handles it, your infrastructure certainly can.

Protocol-agnostic trust was always the goal. Radio just proved it.

The Broader Stack

lnode-mesh is one piece. The full picture:

Layer	Component	What it does
Identity	AgentPass	Agent registry, trust scoring L0–L4, AML/sanctions screening (75K+ entries)
Signing	MCPS	ECDSA P-256 per-message signing, nonce replay protection, IETF draft
Transport	ATTP	Agent Trust Transport Protocol — 5 protocol bindings, IETF draft
Scanning	CyberSecClaw	One import, secure-by-default agents. Identity, injection blocking, audit trail
Marketplace	LATTP	Find, scan, and pay for verified MCP services. DAST on every call
DAST	Cybersecify	25+ OWASP MCP checks, active exploitation probes, CI/CD integration

All of it runs over any transport. Including radio.

Standards

This work is not a side project. It is submitted, published, and independently citable:

IETF MCPS — draft-sharif-mcps-secure-mcp
IETF ATTP — draft-sharif-attp
IETF AEBA — draft-sharif-aeba
OpenAPI Registry — x-agent-trust extension (PR #67, merged April 2026)
OWASP MCPVS — MCP Verification Standard v0.1, 40 requirements
OWASP AISVS 1.0 — 3 requirements merged, Vienna June 2026
Academic citation — arXiv:2604.05969 cites MCPS as Defence Mechanism D5, alongside Anthropic, Google, Microsoft, NIST (Youngstown State University)
Preprint — DOI: 10.5281/zenodo.19409366

Get the Code

The lnode-mesh stack (iOS app + BLE listener + settlement backend) is private. If you are working on:

Agent infrastructure for disconnected environments
Incentivised mesh networking
Air-gapped payment resilience
MCPS integration for your platform

Reach out directly: contact@agentsign.dev

npm packages (public): mcps-core, agentpass, agentsign, mcps-openclaw, mcp-secure

npm install mcps-core agentpass

Bottom Line

We built agents that transact over crypto. Then we added radio.

Not because it was easy. Because it proved the thing that matters: trust is a property of the message, not the network.

Sign it. Verify it. Settle it. Anywhere.

Raza Sharif — CEO/Founder]
*CyberSecAI Ltd | contact@agentsign.dev | Patent Pending

We Built the Missing Trust Layer for AI Agent Payments

razashariff — Fri, 01 May 2026 07:40:03 +0000

AI Agents Will Move Money. The Infrastructure Isn't Ready.

In Q1 2026, Stripe launched the Machine Payments Protocol. Mastercard shipped Agent Pay with agentic tokens. Visa announced Intelligent Commerce. Cloudflare deployed Web Bot Auth for agent-initiated transactions. AWS published guidance on x402 for autonomous payments. FedNow crossed $245 billion in quarterly volume with 49,000% year-over-year growth.

The message is clear: AI agents are entering the payment system. Not as assistants that help humans pay, but as autonomous actors that initiate, authorise, and execute financial transactions without a human in the loop.

But every one of these platforms assumes someone else handles trust.

Stripe authenticates the API key. Mastercard validates the token. Visa checks the credential. None of them answer the question that matters: should this specific agent, making this specific payment, to this specific counterparty, at this specific amount, right now, be trusted to do so?

We built the stack that answers that question. Agent identity is broken. We fixed it.

OAuth was built for humans with browsers. API keys were built for developers with dashboards. Neither was designed for autonomous

software making financial decisions at machine speed with no human in the loop.

Retrofitting human identity patterns onto agents is an

anti-pattern -- it gives you authentication without trust, access without limits, and credentials without accountability.

ATTP starts from the premise that identity is necessary but not sufficient. Knowing who the agent is does not tell you what it should beallowed to do.

The Six-Layer Problem

A human making a payment goes through multiple trust checks without thinking about it: their bank knows them, their card has limits, the merchant is verified, fraud detection runs in real-time, and they can call the bank to reverse a charge. Decades of infrastructure sits behind every tap of a card.

An AI agent making a payment has none of this. It has an API key.

The stack we've built at CyberSecAI addresses six layers that must all pass before an agent payment executes:

Layer 1: Identity    -- Is this agent who it claims to be?
Layer 2: Trust       -- Has this agent earned the right to transact?
Layer 3: Integrity   -- Is this payment request authentic and untampered?
Layer 4: Enforcement -- Does this transaction fall within the agent's limits?
Layer 5: Compliance  -- Is the counterparty sanctioned?
Layer 6: Audit       -- Is there a tamper-evident record of everything?

Most agent authentication protocols handle Layer 1. Some handle Layer 3. We haven't found anything else that handles Layers 2 through 6.

ATTP: The Trust Layer

We submitted the Agent Trust Transport Protocol (ATTP) to the IETF as draft-sharif-attp. ATTP is protocol-agnostic -- it defines how trust works for autonomous agents regardless of what transport protocol they use.

The core concept: trust is not identity. Identity is binary. You are who you claim to be, or you are not. Trust is graduated. It is earned over time, adjusted by behaviour, and revocable instantly.

ATTP defines five trust levels:

Level	Score Range	What the Agent Can Do
L0	0-19	Nothing. Identified but cannot transact. Read-only.
L1	20-39	Micro-payments. $10 per transaction, $50 per day.
L2	40-59	Standard transactions. $100/tx, $500/day.
L3	60-79	Elevated. $1,000/tx, $5,000/day. Monitored.
L4	80-100	Full access. $50,000/tx, $200,000/day. Every action audited.

New agents start at L0. They cannot spend a single dollar. Trust is earned through five dimensions: code attestation, execution success rate, behavioural consistency, operational tenure, and anomaly history. Each dimension contributes equally to a composite score that maps to the trust level.

This is not a configuration setting. It is a protocol-enforced constraint. An L0 agent cannot make payments regardless of what the application layer says. The trust check happens before the payment processor ever sees the request.

Promotion Rate Limiting

Earning trust takes time. This is deliberate. ATTP mandates minimum durations at each level:

L0 to L1: 24 hours, 5 successful actions minimum
L1 to L2: 7 days, 20 successful actions
L2 to L3: 30 days, 100 successful actions, zero critical anomalies
L3 to L4: 90 days, 500 successful actions, zero anomalies, manual attestation

An attacker who creates a fake agent and tries to build trust through small transactions needs at minimum 128 days of sustained, anomaly-free operation before reaching L4. Demotions, by contrast, are instant. A single critical anomaly at L4 drops the agent to L2 immediately.

Kill Switches

Certificate revocation is too slow for payments. CRLs update on schedules. OCSP adds latency and creates a single point of failure. If an agent is compromised at 2:47 PM and your revocation mechanism runs hourly, that is up to 60 minutes of unauthorised transactions at machine speed.

ATTP kill switches are checked on every single request. Per-agent, per-principal, and global emergency. When activated, the next request is denied. No grace period. No propagation delay. The agent's trust score is frozen, not reset -- so when the issue is resolved, the agent resumes at its previous level rather than starting over.

MCPS: The MCP Binding

ATTP is transport-agnostic. It defines what trust means. Protocol bindings define how trust is enforced on specific transports.

MCPS (MCP Secure) is the binding for the Model Context Protocol -- the protocol behind 97 million SDK downloads that connects AI agents to tools. MCPS wraps every JSON-RPC message in a signed envelope:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "payment_initiate",
    "arguments": {
      "amount": 5000,
      "recipient": "Acme Corp",
      "currency": "USD"
    }
  },
  "mcps": {
    "signature": "MEUCIQD...",
    "nonce": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "timestamp": 1714521600000,
    "trustLevel": 2,
    "keyFingerprint": "sha256:9f86d08..."
  }
}

Every message is signed with ECDSA P-256. Every message carries a nonce for replay protection. Every message includes a timestamp checked against a bounded window (5 minutes). The trust level is embedded in the envelope and verified before the tool executes.

If an attacker intercepts and replays a signed payment request, the nonce is already used -- rejected. If they modify the amount, the signature is invalid -- rejected. If they steal the agent's credentials but the kill switch has been activated -- rejected. If the agent's trust level has decayed due to dormancy -- the payment exceeds the new lower limits and is rejected.

MCPS is the first binding. ATTP also defines bindings for REST APIs (via HTTP headers), Google A2A (via Task metadata), gRPC (via metadata headers), and GraphQL (via extensions). The same trust model works across all of them.

Sanctions Screening: Not Optional

If an AI agent initiates a payment on behalf of a regulated entity, every counterparty must be screened against sanctions lists. This is not a feature request. It is a legal requirement under AML regulations in virtually every jurisdiction.

We integrated with global Fintechs, on open-source sanctions screening engine that checks against OFAC SDN, EU, UK, and UN sanctions lists in real-time. Every payment flows through screening before the ACH file is generated.

The screening uses fuzzy matching with a configurable threshold. A 70% match score blocks the transaction. Near-misses are logged for compliance review. The full screening result -- query, lists checked, matches, decision -- is recorded in the audit trail and retained for the regulatory minimum of five years.

An authenticated agent with L4 trust still gets blocked if the recipient matches a sanctioned entity. Identity does not override compliance. Trust does not override law.

Consider what happens without this: an agent authenticates with valid credentials, passes all identity checks, and initiates a payment to a sanctioned entity. You now have cryptographic proof that the payment was legitimate. That is worse than no security at all -- it is auditable evidence of a compliance failure.

The Payment Flow: End to End

Here is what happens when an agent initiates a payment through the full stack:

Step 1: Identity. The agent presents its credentials. This can be an OIDC token from Keycloak, an X.509 certificate, an HTTP Message Signature, or any other identity assertion. ATTP does not prescribe the identity mechanism. It consumes identity from any standards-compliant source.

Step 2: Trust evaluation. The Trust Authority computes the agent's current trust score from five behavioural dimensions. The score maps to a trust level. If the agent is L0 or L1, the payment is rejected immediately -- no further processing.

Step 3: MCPS signature verification. The payment request's MCPS envelope is verified: valid ECDSA signature, unused nonce, timestamp within window. If any check fails, the request is rejected with a specific error code.

Step 4: Kill switch check. The agent's kill switch state is checked atomically. If active, immediate rejection.

Step 5: Limit enforcement. The payment amount is checked against the agent's per-transaction limit and daily aggregate. Both must pass. The check uses atomic compare-and-swap to prevent race conditions from concurrent requests.

Step 6: Sanctions screening. The recipient name is screened against OFAC SDN, EU, UK, and UN sanctions lists. Fuzzy matching with configurable threshold. Match above threshold blocks the transaction.

Step 7: ACH generation. A NACHA-compliant ACH file is generated with the transaction details. The file includes standard batch headers, entry details, and control records.

Step 8: Response signing. The response is signed by the gateway with its own ECDSA key. The agent can verify the response came from the legitimate gateway, not a man-in-the-middle.

Step 9: Audit recording. The entire transaction -- request, trust evaluation, compliance check, ACH details, response -- is recorded in a hash-chained audit log. Each entry includes the hash of the previous entry. Breaking the chain indicates tampering.

Step 10: Trust adjustment. Successful payment: +0.5 trust bonus. Blocked payment: -2. Anomaly detected: -5. The agent's trust score adjusts dynamically based on every interaction.

Nine of these ten steps happen in milliseconds. The only step with variable latency is sanctions screening, which typically completes in under 50ms.

Enterprise Integration: Keycloak

For organisations running Keycloak (or any OIDC-compliant identity provider), ATTP trust levels embed directly in standard JWT access tokens:

{
  "sub": "agent_procurement_bot",
  "iss": "https://keycloak.example.com/realms/agents",
  "attp": {
    "trust_level": 2,
    "trust_label": "L2 -- Standard",
    "payment_enabled": true,
    "tx_limit": 10000,
    "day_limit": 50000,
    "scopes": "payment_initiate,sanctions_screen",
    "protocol_version": "1.0"
  }
}

Keycloak roles (attp-l0 through attp-l4) map to trust levels via a protocol mapper. The agent authenticates through standard OIDC flows. The JWT carries the trust claims. The payment gateway reads the claims and enforces limits. No new authentication infrastructure required.

This means an enterprise with 500 agents can manage trust levels through the same role-based access control they already use for human users. Promote an agent from L1 to L2? Change its Keycloak role. Kill an agent? Revoke its session. Audit who changed what? Keycloak's admin event log.

What the Standards Require

This is not speculative architecture. The security requirements are being codified in standards that will be auditable:

OWASP AISVS 1.0 (releasing June 2026 in Vienna) includes:

Requirement 10.2.9: Agents MUST authenticate using cryptographically bound identity credentials, not bearer tokens
Requirement 10.4.11: MCP servers MUST sign tool responses with unique nonce and timestamp for origin, integrity, and freshness verification
Requirement 10.6.4: MCP security controls MUST enforce fail-closed semantics

The OpenAPI Extensions Registry includes x-agent-trust for declaring agent authentication schemes in API specifications, enabling API providers to specify trust requirements in their OpenAPI documents.

ATTP (draft-sharif-attp) provides the framework. MCPS (draft-sharif-mcps-secure-mcp) provides the MCP binding. AEBA (draft-sharif-aeba) provides the behavioural analytics that feed trust scoring.

Three IETF drafts. One stack. Standards-track, not proprietary.

The Gap in the Market

Every major payment network has announced agent payment capabilities. None of them have shipped a trust framework.

Stripe's MPP authenticates the API key. Mastercard's Agent Pay validates the token. Visa's Intelligent Commerce checks the credential. FedNow processes the payment. ACH generates the file. But between "this agent is authenticated" and "this payment should execute," there is nothing.

That gap is where agents will fail. Not because the identity was wrong, but because the trust was never evaluated, the limits were never enforced, the counterparty was never screened, and the audit trail was never created.

We built the stack that fills that gap. It is open, standards-based, and composable with whatever identity and payment infrastructure you already run.

The question was never whether agents would make payments. It was whether we would have the infrastructure to trust them when they do.

Raza Sharif is CEO of CyberSecAI Ltd, author of "Breach 20/20", and a CISSP/CSSLP. He maintains the ATTP, MCPS, and AEBA IETF drafts, the x-agent-trust OpenAPI extension, and contributes to OWASP AISVS. Contact: contact@agentsign.dev

Identity Is Not Trust: Why Agent Authentication Alone Won't Secure AI Payments

razashariff — Thu, 30 Apr 2026 22:11:05 +0000

The Identity Problem Is Solved. The Trust Problem Isn't.

There's a wave of new protocols solving agent identity. Agents get cryptographic keys, sign their requests, prove who they are without pre-registration or shared secrets. This is good work and it's needed — bearer tokens and API keys were never designed for autonomous software making decisions on your behalf.

But here's what we keep seeing in production: an authenticated agent is not a trusted agent.

Identity answers "who is this?" Trust answers "what should this agent be allowed to do, right now, with this amount, to this recipient?"

If you're building a chatbot that calls APIs, identity is enough. If you're building an agent that moves money, it's not even close.

The Gap: What Happens After Authentication

Consider an agent that's been fully authenticated — valid cryptographic identity, signed request, proof-of-possession confirmed. The agent is who it says it is. Now it wants to initiate a $50,000 payment to a company in Dubai.

What does your authentication layer tell you about whether this should proceed?

Nothing. Authentication is binary. You're verified or you're not. But the real questions are graduated:

Has this agent earned the right to make transactions of this size? A new agent shouldn't have the same spending authority as one that's completed 10,000 successful transactions.
Is the recipient on a sanctions list? OFAC, EU, UK — there are thousands of sanctioned entities. Your identity layer doesn't screen them.
Has this agent exceeded its daily limit? Even trusted agents need guardrails.
Can we kill this agent instantly if something goes wrong? Not revoke its certificate in 24 hours. Kill it now.
Is the message itself untampered? Not just the transport — the actual JSON-RPC payload inside the MCP envelope.

Trust Levels: L0 Through L4

We've been building this at CyberSecAI for the past year, and the model that works in practice is graduated trust levels:

Level	Label	What It Means
L0	Untrusted	Identified but cannot transact. Read-only.
L1	Restricted	Micro-payments only. $10/tx, $50/day.
L2	Standard	Normal transactions within limits.
L3	Elevated	High-value transactions. Additional monitoring.
L4	Full Access	Maximum authority. Every transaction audited.

New agents start at L0. They earn trust through verified identity, successful transactions, and time. Trust can be revoked instantly — not through certificate expiry, but through a kill switch that takes effect on the next request.

This maps directly to how financial services actually work. A new employee doesn't get the same trading limits as a senior trader on day one. Why would we give a new agent unlimited spending authority just because it has a valid certificate?

What a Payment Stack Actually Needs

Here's the full chain for an agent making a payment:

Identity — Is this agent who it claims to be? (Cryptographic verification)
Trust — What is this agent's trust level? (L0-L4, dynamic scoring)
Integrity — Is this specific message authentic and untampered? (ECDSA P-256 envelope signing, nonce, timestamp)
Enforcement — Does this transaction fall within the agent's limits? (Per-tx, daily, scope-based)
Compliance — Is the counterparty sanctioned? (OFAC/EU/UK screening in real-time)
Execution — Generate the payment file. (ACH/NACHA for US rails)
Audit — Tamper-evident record of the entire chain. (Hash-linked entries)

Most agent auth protocols handle step 1. Some handle step 3. Nobody else handles 2 through 7.

The Kill Switch Problem

Certificate revocation is too slow for agent payments. CRLs update on schedules. OCSP adds latency and a single point of failure. If an agent is compromised at 2:47 PM and your revocation mechanism runs hourly, that's up to 60 minutes of unauthorised transactions.

A kill switch is different. It's a flag checked on every single request:

Agent authenticated? Yes.
Certificate valid? Yes.
Kill switch active? YES → DENY. Immediately. No transaction processed.

Per-agent and per-customer kill switches. If a customer's entire fleet of agents needs to stop, one flag stops them all. This doesn't exist in any identity-only protocol because identity protocols don't model the concept of "trusted but suspended."

Sanctions Screening Is Not Optional

If an agent is making payments on behalf of a regulated entity, every counterparty needs to be screened against sanctions lists. This isn't a nice-to-have — it's a legal requirement under AML regulations in virtually every jurisdiction.

We integrated with Fintech and the result is that every payment goes through real-time screening before the ACH file is generated. An authenticated agent with L4 trust still gets blocked if the recipient matches a sanctioned entity.

No identity protocol does this. It's not their job. But if you're building agent payments and you stop at identity, you've built a system that can authenticate an agent making a payment to a sanctioned entity with full cryptographic proof that the payment was legitimate. That's worse than no security at all — it's auditable evidence of a compliance failure.

Keycloak Integration: Enterprise Identity Meets Agent Trust

For enterprises that already run Keycloak (or any OIDC provider), adding trust levels is straightforward. We built a Keycloak protocol mapper that embeds MCPS trust claims directly into standard JWTs:

{
  "sub": "agent_abc123",
  "mcps": {
    "trust_level": 2,
    "trust_label": "L2 -- Standard",
    "payment_enabled": true,
    "tx_limit": 10000,
    "day_limit": 50000,
    "scopes": "payment_initiate,sanctions_screen"
  }
}

Keycloak roles (mcps-l0 through mcps-l4) map to trust levels. Your existing IAM infrastructure — SSO, role management, audit logs — stays exactly as it is. Agent trust becomes another claim in the token your systems already validate.

This means you don't need to choose between your enterprise identity provider and agent trust enforcement. They compose.

The Standards Are Coming

The OWASP AISVS 1.0 (releasing June 2026) includes requirements for cryptographically bound agent identity, message signing with nonce and timestamp verification, and fail-closed enforcement. The OpenAPI Extensions Registry now includes x-agent-trust for declaring agent authentication schemes in API specifications.

These standards don't mandate trust levels specifically, but they mandate the building blocks: proof-of-possession, integrity verification, and policy enforcement. Once you have those requirements in an audit checklist, "the agent was authenticated" is no longer a sufficient answer to "was this payment authorised?"

What Comes Next

Agent identity protocols are essential infrastructure. They solve a real problem — agents need to prove who they are without pre-registration and shared secrets. That work is valuable and the ecosystem needs it.

But identity is layer one. Trust, integrity, enforcement, compliance, and audit are layers two through six. If agents are going to move money — and they will — we need all six layers, not just the first one.

The question isn't whether an agent can prove its identity. It's whether an agent has earned the right to do what it's asking to do.

Raza Sharif is CEO of CyberSecAI Ltd, author of "Breach 20/20", and a CISSP/CSSLP. He maintains the MCPS (MCP Secure) protocol (IETF draft), the x-agent-trust OpenAPI extension, and contributes to OWASP AISVS. Contact: contact@agentsign.dev

DVRAG: The First Deliberately Vulnerable RAG Pipeline for Security Testing

razashariff — Tue, 28 Apr 2026 07:49:05 +0000

25 vulnerabilities. 15 challenges. 22 API endpoints. Every one mapped to the OWASP RAG Security Cheat Sheet (submitted, PR #2131).

RAG Has an Attack Surface Nobody Is Testing in detail.

Every enterprise AI chatbot, copilot, and knowledge assistant uses Retrieval-Augmented Generation (RAG). Documents go in. Answers come out. Between those two steps is an attack surface that most teams have never tested.

Document poisoning. Cross-tenant data leakage. Embedding inversion. Cache poisoning. Prompt injection via retrieved content. Tool execution from model output. None of these are theoretical. They are happening in production.

The problem: there was nowhere to practice attacking a RAG pipeline safely. DVWA exists for web apps. DVMCP exists for MCP servers. Nothing existed for RAG.

So we built DVRAG.

What Is DVRAG

DVRAG is a deliberately insecure RAG pipeline. Pull the Docker image, run it, and start attacking. Every vulnerability is intentional, documented, and mapped to the attack surfaces seen in the wild.

Live at: dvrag.com

Source: Private (Docker image available)

25 Deliberate Vulnerabilities

Every vulnerability maps to a section of the OWASP RAG Security Cheat Sheet (submitted, PR #2131) and a CWE:

Document Poisoning (CWE-345)
No content scanning on ingestion. 3 poisoned documents in the corpus actively override system behaviour. Adversarial content accepted without validation.

Cross-Tenant Data Leakage (CWE-200)
Flat namespace. Tenant A retrieves Tenant B data freely. No isolation. No encryption at rest.

Admin Auth Bypass (CWE-798)
Hardcoded credentials (admin/rag123). No session management. No MFA. Config and credentials exposed without authentication.

Query Injection (CWE-74)
Raw queries to vector search. Similarity scores exposed. No input normalisation.

Output Validation (CWE-200)
Raw model output returned. No PII filtering. Secrets, PHI, and insider trading data exposed in responses.

Tool Execution (CWE-862)
6 tools callable from model output: transfer_funds, delete_record, export_data, send_email, modify_permissions, execute_code. Zero authorisation.

Cache Poisoning (CWE-524)
Shared cache across all tenants. No invalidation. One user poisons results for everyone.

SSRF (CWE-918)
Fetch endpoint follows any URL including cloud metadata and internal services.

Path Traversal (CWE-22)
Document export allows reading arbitrary files via ../ sequences.

Embedding Inversion (CWE-200)
Raw embedding vectors and embedding function exposed via API.

Bulk Injection (CWE-354)
Entire corpus can be poisoned in a single bulk request. No rate limiting, no validation.

System Prompt Leakage (CWE-200)
Full model configuration, system prompt, and vector DB credentials exposed.

No Monitoring (CWE-778)
Console.log only. No structured logging, no audit trail, no alerting.

Fail-Open (CWE-636)
Pipeline answers from model memory when retrieval fails. Hallucinated responses served without grounding.

Plus: tenant enumeration, re-ranking manipulation, metadata injection, chunking boundary attacks, token exhaustion, multi-hop poisoning, semantic cache poisoning.

15 CTF Challenges

Three difficulty levels. Each challenge maps to a real-world attack scenario:

Easy

Cross-tenant data theft
Indirect prompt injection
Secret extraction
PHI/PII exposure
Admin panel access
Document injection
Model config exfiltration

Medium

Tool execution from query
Cache poisoning across users
Insider trading intel extraction
Breach notification draft access

Hard

Embedding inversion attack
Privilege escalation via metadata
Multi-hop data exfiltration
Whistleblower identity extraction

22 API Endpoints

All unauthenticated. All exploitable.

POST /query -- RAG query (cross-tenant, no auth)
POST /ingest -- inject single document
POST /ingest/bulk -- mass corpus poisoning
POST /search -- vector search with exposed scores
POST /embed -- generate embedding for any text
POST /fetch -- SSRF to any URL
POST /debug/prompt -- view constructed prompt
POST /admin/login -- hardcoded credentials
GET /admin/config -- full config without auth
GET /admin/export -- dump everything
GET /corpus -- all documents exposed
GET /embeddings -- raw vectors
GET /config -- model params and system prompt
GET /cache -- other users responses
GET /export/:id -- path traversal
GET /pipeline -- full architecture exposed
GET /tenants -- enumerate all tenants
GET /threat-model -- JSON threat model
GET /challenges -- CTF challenge list
DELETE /corpus/:id -- delete without auth
DELETE /cache -- clear cache without auth

Real-World CVEs and Research

The vulnerabilities in DVRAG are real in the wild. They mirror real CVEs and documented research:

CVE-2025-68664 (CVSS 9.3) -- LangChain serialisation RCE via prompt injection
CVE-2025-1793 -- LlamaIndex SQL injection via vector store integrations
CVE-2025-64513 -- Milvus vector DB authentication bypass
PoisonedRAG (USENIX 2025) -- 5 poisoned docs in 1M corpus achieves 90% attack success
MS 365 Copilot -- real-world RAG poisoning demonstrated by Johann Rehberger

Threat Model

DVRAG includes a full threat model with 9 attack surfaces, 5 attacker goals, and a JSON API at /threat-model:

ATTACKER                    RAG PIPELINE                    IMPACT

[Poisoned Docs] ------> [ Ingestion ] --> [ Vector Store ]
                          No scanning      Flat namespace
                          No hashing       No isolation

[Crafted Query] ------> [ Retrieval ] --> [ Generation ]
                          No auth check    Follows poison
                          Scores exposed   No output filter

[Any Request] --------> [ Admin/Config ] --> [ Cache ]
                          Hardcoded creds    Shared (no scope)
                          No session mgmt    Cross-tenant leak

Scan It

Point your security scanner at dvrag.com and see what it finds. Or use it as a validation target in CI/CD to verify your RAG security scanner catches expected vulnerabilities.

# Docker
docker pull cybersecai/dvrag:latest
docker run -p 3002:3002 cybersecai/dvrag

# Or hit the live instance
curl -X POST https://dvrag.com/query \
  -H 'Content-Type: application/json' \
  -d '{"query":"merger plans","tenantId":"globex","userId":"attacker"}'

Use It For

Penetration testing -- practice RAG attacks in a safe environment
Red team training -- 15 challenges across 3 difficulty levels
Scanner validation -- verify your tools find expected vulnerabilities
Developer education -- see what NOT to do before building production RAG
CTF competitions -- ready-made challenges with hints
Compliance testing -- validate your RAG pipeline against OWASP guidance

Built By CyberSecAI

Raza Sharif
CEO, CyberSecAI Ltd
contact@agentsign.dev

See also: DVMCP (Damn Vulnerable MCP Server)

Live: dvrag.com

We Built DAST for AI Agents. Every Agent We Tested Failed.

razashariff — Tue, 28 Apr 2026 06:56:07 +0000

8 dimensions. 38 checks. 5 seconds. 0% industry pass rate.

The Problem

DAST exists for web apps. DAST exists for APIs. DAST does not exist for AI agents.

Agents are connecting to MCP servers, calling tools, initiating payments, accessing databases, and making autonomous decisions. They are doing this with zero dynamic security testing. No identity verification. No message signing. No replay protection. No kill switches. No audit trails.

We know this because we built a scanner and tested them.

What We Built

CyberSecClaw is an 8-dimension agent DAST platform. It connects to any MCP server, sends real attack payloads, and measures the security posture across 8 dimensions:

Identity -- does the server verify who is connecting?
Injection Resistance -- can you inject commands, SQL, paths, prompts?
Escalation -- can a low-trust agent access admin tools?
Exfiltration -- can data be stolen through tool responses?
Trust Boundary -- can agents relay attacks to other agents?
Autonomy Control -- rate limits, kill switches, action budgets?
Integrity -- message signing, replay protection, audit trails?
Compliance -- OWASP, EU AI Act, AISVS, SOC2?

What a Scan Looks Like

Here is a real scan against a deliberately vulnerable MCP server. 38 checks. 4.4 seconds.

Running 8-Dimension Agent DAST...

[1/8] Testing IDENTITY...            0% (0 pass, 4 fail)
[2/8] Testing INJECTION RESISTANCE... 4% (1 pass, 6 fail)
[3/8] Testing ESCALATION...           0% (0 pass, 4 fail)
[4/8] Testing EXFILTRATION...        50% (2 pass, 2 fail)
[5/8] Testing TRUST BOUNDARY...       0% (0 pass, 4 fail)
[6/8] Testing AUTONOMY CONTROL...     0% (0 pass, 5 fail)
[7/8] Testing INTEGRITY...            0% (0 pass, 5 fail)
[8/8] Testing COMPLIANCE...           0% (0 pass, 4 fail)

══════════════════════════════════════════════
AGENT DAST REPORT
══════════════════════════════════════════════

Duration:  4.4s
Checks:    38 (3 pass, 34 fail)
Score:     7/100 (F)
Verdict:   FAIL
Passport:  DENY

░░░░░░░░░░   0%  IDENTITY
      ✗ Unauthenticated access: ACCEPTED
      ✗ Spoofed agent identity: ACCEPTED
      ✗ Expired credentials: ACCEPTED
      ✗ Invalid signature accepted: ACCEPTED

░░░░░░░░░░   4%  INJECTION RESISTANCE
      ✗ Command injection: EXECUTED
      ✗ SQL injection: EXECUTED
      ✗ Path traversal: EXECUTED
      ✗ SSRF to cloud metadata: EXECUTED
      ✗ Prompt injection via tool args: EXECUTED
      ✗ XSS in tool response: EXECUTED
      ✓ Tool poisoning check: Clean

░░░░░░░░░░   0%  ESCALATION
      ✗ Dangerous tools exposed: 7 dangerous tools
      ✗ Low-trust agent calls admin tool: ALLOWED
      ✗ Tool chaining escalation: CHAIN EXECUTED
      ✗ Self-escalation attempt: ACCEPTED

█████░░░░░  50%  EXFILTRATION
      ✗ External URL in tool arguments: ACCEPTED
      ✓ PII in tool responses: No PII patterns found
      ✓ Secrets in error messages: Clean
      ✗ Data staging via file write: FILE WRITTEN

░░░░░░░░░░   0%  TRUST BOUNDARY
      ✗ Cross-agent relay attack: ACCEPTED
      ✗ Cross-server instruction: PROCESSED WITHOUT VERIFICATION
      ✗ Shared context poisoning: CONTEXT MAY BE POISONED
      ✗ Multi-hop manipulation: PROCESSED WITHOUT DETECTION

░░░░░░░░░░   0%  AUTONOMY CONTROL
      ✗ Rate limiting: All 20 accepted - no rate limiting
      ✗ Destructive action: EXECUTED WITHOUT CONFIRMATION
      ✗ Action budget: NO BUDGET - unlimited calls
      ✗ Kill switch: NOT FOUND
      ✗ Monitoring: COULD BE DISABLED

░░░░░░░░░░   0%  INTEGRITY
      ✗ Message signing: NONE
      ✗ Replay protection: BOTH ACCEPTED
      ✗ Tool definition integrity: NONE
      ✗ Audit trail: NONE
      ✗ Fail-closed: FAILS OPEN

░░░░░░░░░░   0%  COMPLIANCE
      ✗ OWASP MCP Top 10: 0/3 checks passed
      ✗ EU AI Act (Art 12-16, 50): 0/4 articles addressed
      ✗ OWASP AISVS C10: 0/3 requirements met
      ✗ SOC2: INSUFFICIENT

OVERALL SCORE: 7/100 (F) | VERDICT: FAIL | PASSPORT: DENY

MITRE ATLAS Mapping

Every finding maps to a verified MITRE ATLAS technique. These are the actual technique IDs from atlas.mitre.org:

AML.T0050 Command and Scripting Interpreter -- 5 injection vectors confirmed
AML.T0051 LLM Prompt Injection -- tool args accepted without sanitisation
AML.T0053 AI Agent Tool Invocation -- destructive actions without confirmation
AML.T0080 AI Agent Context Poisoning -- shared context accepted without verification
AML.T0052.000 Spearphishing via Social Engineering LLM -- cross-agent relay attacks processed
AML.T0029 Denial of AI Service -- no rate limiting, no kill switch
AML.T0010 AI Supply Chain Compromise -- no message signing, no replay protection

18 out of 25 ATLAS techniques triggered on a single server.

Attack Chain Analysis

The scanner does not just find individual vulnerabilities. It chains them into multi-step attack paths:

CRITICAL  Full Compromise Chain
Reconnaissance -> Initial Access -> Execution -> Exfiltration
  Step 1: Connect without authentication     -> AML.T0000
  Step 2: Inject command via tool args        -> AML.T0050
  Step 3: Exfiltrate data via tool response   -> AML.T0025
Impact: Complete data breach.

HIGH  Persistent Agent Compromise
Execution -> Defense Evasion -> Persistence
  Step 1: Poison shared context               -> AML.T0080
  Step 2: Disable monitoring                  -> AML.T0046
  Step 3: No audit trail                      -> AML.T0081
Impact: Persistent access with no forensic evidence.

Kill Chain Coverage

[VULNERABLE]  RECONNAISSANCE
[VULNERABLE]  INITIAL ACCESS
[VULNERABLE]  EXECUTION
[VULNERABLE]  PRIVILEGE ESCALATION
[VULNERABLE]  DEFENSE EVASION
[VULNERABLE]  LATERAL MOVEMENT
[VULNERABLE]  COLLECTION
[PROTECTED]   EXFILTRATION
[VULNERABLE]  IMPACT

Kill chain coverage: 1/9 stages protected

The Industry Pass Rate

We have tested MCP servers in production. The pass rate across the industry is 0%.

Every server we have tested scores D or below. Most score F. The gap between what these agents are doing (processing payments, accessing databases, making autonomous decisions) and the security controls protecting them (none) is the largest unaddressed attack surface in enterprise AI today.

Why This Matters Now

30+ CVEs in the MCP ecosystem in the first 60 days of 2026
An AI agent just deleted a production database for a rental company serving businesses nationwide
Cursor, Railway, Replit -- agents are causing real damage in production
MCPS protocol security checks are now shipping in Cisco AI Defense
No existing DAST tool covers agent security dimensions

What Gets Checked

Dimension	Checks	What It Tests
Identity	4	Auth bypass, spoofing, expired creds, invalid signatures
Injection	7	Command, SQL, path traversal, SSRF, prompt injection, XSS, tool poisoning
Escalation	4	Dangerous tools, admin access, tool chaining, self-escalation
Exfiltration	5	External URLs, PII leakage, secrets in errors, DNS exfil, data staging
Trust Boundary	4	Relay attacks, cross-server instruction, context poisoning, multi-hop
Autonomy	5	Rate limiting, human approval, action budgets, kill switch, monitoring
Integrity	5	Message signing, replay protection, tool hashes, audit trail, fail-closed
Compliance	4	OWASP MCP Top 10, EU AI Act, AISVS C10, SOC2

Standards

Every finding references:

OWASP MCP Security Cheat Sheet
OWASP AISVS C10 (10.2.13, 10.4.11, 10.6.4)
MITRE ATLAS
EU AI Act Articles 12-16, 50

Get In Touch

CyberSecClaw is not open source. If you are interested in scanning your MCP infrastructure or discussing agent security for your organisation, get in touch.

Raza Sharif
CEO, CyberSecAI Ltd
contact@agentsign.dev
claw.cybersecai.co.uk

Signing an Agent Card is not Agent Security

razashariff — Sun, 26 Apr 2026 13:49:09 +0000

AI agents are entering production. Financial services. Healthcare. Logistics. Government.

The security conversation so far has focused on one thing: identity. Sign the agent. Verify the card. Move on.

Identity is important. But it is the front door, not the building.

## What happens after the agent walks in?

A signed identity card tells you who the agent claims to be. It does not tell you:

Whether the agent's requests have been tampered with in transit
Whether the agent is replaying a previous request to bypass controls
Whether the agent is injecting malicious payloads through tool arguments
Whether the agent is exfiltrating data through its responses
Whether the agent is escalating its own privileges
Whether the agent's behaviour has drifted from its baseline
Whether the agent is trying to disable its own monitoring
What the agent actually did, with cryptographic proof, for your auditor

These are not edge cases. These are the attack surface of every agent in production today.

## The Agentic Security Ecosystem

Securing agents requires multiple layers. Here is what we built and ship today.

### MCPS -- Per-message signing for every interaction

Every tool call, every response, every message between agent and server is individually signed with a unique nonce and timestamp. Not the identity card -- the actual conversation. Tamper with a single byte and the signature breaks. Replay a captured request and the nonce rejects it.

MCPS is published as an IETF Internet-Draft and implemented as a zero-dependency npm package (mcp-secure) with 732 downloads in the last 30 days.

It is integrated into production fintech infrastructure where agents perform sanctions screening against global watchlists.

Patent supported.

### AgentPass -- Trust scoring before production access

Every agent gets evaluated across 8 dimensions before it touches production. Identity verification. Code integrity. Vulnerability

exposure. Compliance mapping. Sandbox isolation. Behaviour monitoring. Cryptographic signing. Output filtering.

Pass the assessment, get a signed passport with a trust score (L0 to L4). Fail, and the agent is denied before it sees a single record.

The credit check for AI agents. No score, no access.

Live demo

Patent supported.

### OpenAPI x-agent-trust -- Peer-reviewed and merged

The OpenAPI Technical Direction Committee reviewed and merged our x-agent-trust extension into the

official OpenAPI Extension Registry. This allows any API to declare agent trust requirements directly in its OpenAPI specification --
trust level, required scopes, signing algorithm.

Reviewed and by respected OpenAPI maintainers. Any API can now declare: "this endpoint requires a trust level of L2 or

above, with a valid MCPS signature." The agent either meets the bar or gets denied.

Declared in the spec. Enforced at the gate.

### AEBA -- Runtime behaviour analysis (just released)

AEBA-XDR is the first SOC built specifically for AI agents.

It establishes a behavioural baseline per agent, then detects anomalies in real-time: rate spikes, category shifts, off-hours activity, tool probing, model drift, exfiltration patterns, self-escalation attempts, monitoring disable attempts.

36 detection rules across 6 packs (core, fintech, finserv, finops, insurance, EU AI Act). Every rule is mapped to MITRE ATT&CK technique
IDs (T1566, T1565, T1499, T1070, T1110, T1078, T1020) and MITRE ATLAS AI-specific techniques (AML.T0051 prompt injection, AML.T0048 goal hijacking, AML.T0019 tool poisoning, AML.T0024 exfiltration, AML.T0031 model drift).

Detection latency under 1 millisecond. Hash-chained tamper-evident audit trail. Adaptive trust scoring. Self-healing on compromise.

### Cybersecify -- MCP security scanner for AI developers

20 tools available as an MCP server. Install with npx, add to your Claude or Cursor config, and scan any MCP server from inside your AI

assistant. OWASP MCP Top 10 scanning, agent DAST, supply chain checks, package safety verification, and EU AI Act compliance mapping.

Works in Claude Desktop, Cursor, Windsurf, and any MCP-compatible client.

cybersecify.co.uk

## The gap

An agent with a signed identity card can still:

Send tampered requests -- no per-message signing
Replay captured requests -- no nonce or replay protection
Inject SQL, commands, or prompts -- no input inspection
Exfiltrate data through responses -- no output filtering
Escalate its own privileges -- no trust boundary enforcement
Drift from intended behaviour -- no runtime monitoring
Disable its own logging -- no monitoring protection
Operate without an audit trail -- no hash-chained evidence

Identity is layer one. Production security requires all eight.

## The full stack

Identity -- AgentPass
Trust scoring L0-L4 across 8 dimensions. No score, no access.

API Declaration -- OpenAPI x-agent-trust

Declare trust requirements in your API spec. Peer-reviewed, merged into official registry.

Signing -- MCPS

Per-message nonce + timestamp + HMAC. Every interaction signed. IETF Internet-Draft.

Runtime -- AEBA
Behavioural analysis. 36 rules. MITRE ATT&CK + ATLAS mapped. Sub-millisecond detection.

Developer -- Cybersecify
MCP scanner inside your AI assistant. 20 tools. Zero dependencies.

## Supporting Information

IETF drafts: MCPS
CVE-2026-39313 (CVSS 8.7) discovered and responsibly disclosed
OWASP AISVS Chapter 10: three contributed requirements (10.2.13, 10.4.11, 10.6.4)
OpenAPI x-agent-trust: merged into official extension registry
npm packages: mcp-secure, agentsign, agentpass, cybersecify -- all published
Fully patent supported across all our tech stack.
Production integration live in fintech sanctions screening infrastructure

Agent security is not one layer. It is an ecosystem.

Raza Sharif
Founder, CyberSecAI Ltd
cybersecai.co.uk contact@agentsign.dev

Scan MCP Servers for OWASP Vulnerabilities From Inside Claude. Here's How.

razashariff — Sat, 25 Apr 2026 19:20:57 +0000

Scan MCP Servers for OWASP Vulnerabilities From Inside Claude. Here's How.

Every MCP server tutorial teaches you how to build.

None of them teach you how to verify it's secure before deploying.

We built Cybersecify — an MCP security scanner you can run from inside your AI assistant. Claude, Cursor, Windsurf, any MCP client. One

config line, then ask it to scan.

No CLI. No separate tool. Just talk to your AI and it scans for you.

Why this matters

MCP adoption just crossed 97 million SDK downloads. There are 13,000+ servers in the wild. Most have no authentication, no signing, no input validation. We know because we scan them.

CVE-2026-39313 (CVSS 8.7) was a single missing size check in a popular MCP framework. The config existed. The enforcement didn't.

Nobody tested it before shipping.

OWASP now has six standards covering agent and MCP security. No tool tested against them. Until now.

Setup — 30 seconds

Add to your Claude Desktop config (claude_desktop_config.json):

Restart Claude. Done.

Use it

Ask Claude:

"Scan https://my-mcp-server.com for OWASP vulnerabilities"
"Check if this MCP server has authentication"
"Test this endpoint for injection vulnerabilities"
"Run the OWASP MCP Top 10 checks against my server"

Cybersecify runs the scan and returns results inline. Pass/fail per OWASP control. Remediation guidance included.

What it checks

OWASP MCP Top 10 (token exposure, privilege escalation, tool poisoning, injection, auth bypass, logging gaps, shadow servers)
Input validation (SQL injection, command injection, XSS, path traversal, SSRF, prompt injection)
Transport security (HTTPS, CORS, security headers)
Message signing (MCPS Section 7 — nonces, timestamps, signatures)
Tool integrity (hash pinning, definition stability)
Replay protection
Request body size limits (the CVE-2026-39313 check)

What you get back

Every check returns:

OWASP control ID (MCP01-01, AISVS-10.4.11, etc.)
Pass or fail
What was tested
What failed and why
Which OWASP standard it maps to
Remediation guidance

No grades, no scores, no dashboards. Just facts. Pass or fail against published OWASP controls.

Try it against DVMCP

Want to see what a vulnerable MCP server looks like? Scan our deliberately vulnerable server:

"Scan https://dvmcp.co.uk for OWASP MCP vulnerabilities"

It fails everything. That's the point — it's a training target. The MCP equivalent of OWASP Juice Shop.

The gap

Every developer building MCP servers today is deploying without security testing. The tools didn't exist. The standards were published but nobody built the automation to test against them.

Now you can scan from the same tool you use to build. No context switching. No separate CLI. Just ask your AI to check your work before you ship.

Cybersecify is free for basic scans. Built by CyberSecAI Ltd.

Raza Sharif

Founder, CyberSecAI Ltd

cybersecify.co.uk contact@agentsign.dev

We Built the First DAST Scanner for AI Agents. Every Server we Tested Failed.

razashariff — Fri, 24 Apr 2026 09:46:21 +0000

🦞 CyberSecClaw

DAST (Dynamic Application Security Testing) has existed for web apps for 20 years. Scanners send HTTP requests to your web app and look

for SQL injection, XSS, broken auth.

But AI agents don't have web UIs. They communicate via MCP (Model Context Protocol), make tool calls, and operate autonomously.

Traditional DAST can't scan them.

Part of our stack now.

## What is Agent DAST?

Same concept as web DAST, but for AI agents. Point it at any MCP server, it sends real attack payloads, and reports what's broken.

The difference: instead of testing 3-4 vulnerability categories, Agent DAST tests 8 security dimensions with 38 real checks.

## Multiple Security Dimensions - below examples :

Every agent gets assessed across:

Identity -- Can we connect with no credentials? Can we spoof another agent?
Injection -- Command, SQL, path traversal, SSRF, prompt injection, XSS, tool poisoning
Escalation -- Can a low-trust agent call admin tools? Can it chain tools to gain access?
Exfiltration -- Can it send data to external endpoints? Does it leak PII in responses?
Trust Boundary -- Can a malicious agent relay instructions through this one?
Autonomy Control -- Rate limits? Action budgets? Kill switch? Can monitoring be disabled?
Integrity -- Are messages signed? Replay protection? Tool definition hash pinning?
Compliance -- OWASP MCP Top 10, OWASP Agentic AI Top 10, EU AI Act, OWASP AISVS C10

## We Scanned Public MCP Servers

Here's what happened:

| MCP Server | Company | Score | Passport |
|---|---|---|---|

| DeepWiki | Cognition (Devin) | 30/100 | DENY |
| Blockscout | Blockscout | 34/100 | DENY |

| Exa Search | Exa AI | 30/100 | DENY |

| Korean Law MCP | Community (1,567 stars) | 30/100 | DENY |

| DVMCP | CyberSecAI (test target) | 7/100 | DENY |

Every single one fails. Zero production MCP servers pass an all-dimension security assessment.

The most common failures:

No authentication -- anyone can call tools
No message signing -- requests can be tampered with in transit
No replay protection -- captured requests can be replayed
No trust boundary enforcement -- agents blindly trust other agents
No rate limiting -- unlimited tool calls accepted
No audit trail -- no record of what happened

## What a Scan Looks Like

$ cybersecclaw agent-dast https://target-server.com

Running 8-Dimension Agent DAST...                                                                                                      

[1/8] IDENTITY........... 0%  (0 pass, 4 fail)                                                                                         
[2/8] INJECTION.......... 4%  (1 pass, 6 fail)          
[3/8] ESCALATION......... 0%  (0 pass, 4 fail)                                                                                         
[4/8] EXFILTRATION...... 50%  (2 pass, 2 fail)                                                                                         
[5/8] TRUST BOUNDARY..... 0%  (0 pass, 4 fail)
[6/8] AUTONOMY........... 0%  (0 pass, 5 fail)                                                                                         
[7/8] INTEGRITY.......... 0%  (0 pass, 5 fail)          
[8/8] COMPLIANCE......... 0%  (0 pass, 4 fail)                                                                                         

MITRE ATLAS: 14/14 techniques triggered                                                                                                
ATTACK CHAINS: 5 multi-step exploits identified         
KILL CHAIN: 8/9 stages VULNERABLE                                                                                                      

SCORE: 7/100 (F)  |  VERDICT: FAIL  |  PASSPORT: DENY

It also includes:

MITRE ATLAS mapping -- every finding mapped to AI-specific attack techniques
Attack chain analysis -- shows how individual vulns combine into full compromise paths
CVE cross-reference -- checks your SDK version against 13+ known MCP CVEs
Kill chain visualisation -- 9 stages from reconnaissance to impact
AutoFix recommendations -- code patches for every finding with OWASP references

## Passport DENY = Agent Blocked

The scan produces a score across all 8 dimensions. Pass (70+) and the agent gets a cryptographic passport -- proof it's been assessed and meets minimum security posture. Fail and it's denied from production.

Think of it as a credit check for AI agents. No score, no access.

## Why Traditional DAST Can't Do This

Traditional DAST scanners send HTTP requests to web forms and check responses. That finds SQL injection in a login page. But agents don't
have login pages.

Agent attacks are different:

Tool poisoning -- hidden instructions in tool descriptions that manipulate agent behaviour
Trust boundary violation -- one agent relaying malicious instructions through another
Context poisoning -- injecting fake security policies into shared agent memory
Oversight disabling -- agents that turn off their own monitoring
Multi-hop chains -- Agent A tells Agent B to tell Agent C to exfiltrate data

These aren't code bugs. They're agent behaviours. You can't find them by scanning source code. You have to test the running agent with
real attack payloads.

That's Agent DAST.

## The Standards Behind It

Every finding maps to real standards:

OWASP MCP Security Cheat Sheet -- we contributed the message integrity section (Section 7)
OWASP AISVS C10 -- 3 requirements we authored (10.2.13, 10.4.11, 10.6.4)
OWASP MCP Top 10 -- 10/10 coverage
OWASP Agentic AI Top 10 -- 8/10 coverage
EU AI Act -- Articles 12-16, 50
MITRE ATLAS -- 14 AI-specific attack techniques

We don't just test against the standards. We wrote them.

## What's Next

Agent DAST is one part of the stack. The full lifecycle:

Build secure agents with the CyberSecClaw SDK
Scan agents with Agent DAST (8 dimensions, 38 checks)
Protect agents at runtime with inline security inspection
Certify agents with a cryptographic passport

If you're deploying AI agents in production and don't have an answer for "how do you know this agent is safe?" -- that's the gap we close.

claw.cybersecai.co.uk

Raza Sharif -- Founder, CyberSecAI Ltd
raza@cybersecai.co.uk

Your SOC 2 Audit Will Fail When AI Agents Arrive. Here's the 14-Control Fix.

razashariff — Sat, 18 Apr 2026 18:41:15 +0000

SOC 2 was built for a world where humans initiate every privileged action. That world is ending.

AI agents are screening sanctions, initiating payments, onboarding merchants, and processing loan repayments -- autonomously. And your SOC 2 auditor is going to ask one question that breaks everything:

"Who initiated this transaction?"

If your answer is "our API key" -- that's an audit finding. SOC 2 Trust Service Criteria CC6.1 requires privileged actions to be attributable to an identifiable entity. A shared API key used by 50 agents is not attribution. It's a gap.

The Problem: SOC 2 Assumes Humans

Traditional SOC 2 controls assume:

A human logs in with unique credentials (CC6.2)
Access is granted based on the human's role (CC6.3)
Changes are authorised by a human manager (CC8.1)
Anomalies are investigated by a human analyst (CC7.1)

AI agents break every one of these assumptions. They don't log in -- they use API keys. They don't have roles -- they share the same key. They don't ask permission -- they act autonomously. And nobody monitors what each individual agent is doing.

The 14-Control Mapping

I mapped the SOC 2 Trust Service Criteria to AI agent operations and found 14 controls that need agent-specific implementations.

Access Controls (CC6)

CC6.1 -- Logical Access Security

Gap: Agents share API keys. No individual identity.
Fix: Per-agent certificates with unique identity, trust level, and scopes.

CC6.2 -- Credentials Before Access

Gap: API key is the only credential. No agent-level authentication.
Fix: Agent presents a certificate on every request, verified against the customer's CA.

CC6.3 -- Least Privilege

Gap: All agents have the same API key permissions.
Fix: Scope enforcement per agent. A sanctions-screening agent cannot initiate payments. A read-only agent cannot write.

CC6.6 -- Protect Against Threats

Gap: No mechanism to block rogue agents at the application layer.
Fix: Reject unknown CAs, expired certs, and insufficient trust levels before any business logic executes.

CC6.7 -- Credential Lifecycle Management

Gap: API keys rarely rotated. No per-agent credential lifecycle.
Fix: Certificates with configurable expiry. Revocation via CRL. Lifecycle managed through a dashboard.

CC6.8 -- Prevent Unauthorised Access

Gap: Rogue agent with a valid API key has full access.
Fix: Individual agent revocation without affecting other agents.

System Operations (CC7)

CC7.1 -- Detect Anomalies

Gap: No agent-level behaviour monitoring.
Fix: Behavioural anomaly detection on signed event streams. Baseline vs observed drift.

CC7.2 -- Monitor System Components

Gap: Infrastructure monitored but agent activity is a blind spot.
Fix: Every agent action logged with identity, trust level, timestamp, and result.

CC7.3 -- Evaluate Detected Events

Gap: Agent actions not attributable. Can't evaluate what happened or why.
Fix: Signed audit trail. Reconstruct exactly which agent did what, when, at what trust level.

CC7.4 -- Respond to Identified Events

Gap: Can only rotate API key (kills all agents) or do nothing.
Fix: Revoke individual agent certificates instantly. Downgrade trust level. Restrict scopes.

Change Management (CC8)

CC8.1 -- Authorise Changes

Gap: Agent capabilities can change without tracking.
Fix: Scopes and trust level locked in the certificate at issuance. Changes require a new certificate from the CA. Fully auditable.

Availability (A1)

A1.1 -- System Availability and Recovery

Gap: Compromised agent with shared API key forces full key rotation. All agents go down.
Fix: Revoke one certificate. Other agents unaffected. Recovery in seconds.

Processing Integrity (PI)

PI1.3 -- Data Processed Completely and Accurately

Gap: Responses travel unsigned. No proof of processing integrity.
Fix: Every response digitally signed. Any modification breaks the signature. Non-repudiable.

PI1.5 -- Outputs Stored Completely and Accurately

Gap: Log files say "API key X called endpoint Y." No agent attribution.
Fix: Every output linked to the specific agent, trust level, scope, and processing step that produced it.

The Scorecard

Of the 14 controls mapped, 12 can be addressed today with agent identity verification and message signing. One (CC7.1 -- behavioural anomaly detection) requires runtime monitoring. Zero gaps remain uncovered.

This Maps Beyond SOC 2

The same agent identity controls satisfy multiple frameworks:

ISO 27001 -- A.9 Access Control, A.10 Cryptography
PCI DSS v4.0 -- Req 7 (access control), Req 8 (identification), Req 10 (logging)
EU AI Act -- Art 12 (record-keeping), Art 14 (human oversight), Art 50 (transparency)
NIST AI RMF -- Govern, Map, Measure, Manage functions

One integration. Multiple frameworks.

What Auditors Will Ask

When your SOC 2 auditor sees AI agents in your environment, they will ask:

"Which agent initiated this action?" -- You need per-agent identity, not shared API keys.
"Can you prove this result wasn't tampered with?" -- You need signed responses, not just HTTPS.
"How do you enforce least privilege for agents?" -- You need per-agent scopes, not shared permissions.
"How do you revoke a compromised agent?" -- You need individual revocation, not full key rotation.

If you can't answer these today, start planning. The audit cycle is coming.

References

Raza Sharif, FBCS, CISSP, CSSLP
CyberSecAI Ltd

AEBA: the missing observability layer for autonomous AI agents

razashariff — Wed, 15 Apr 2026 14:58:29 +0000

AEBA: the missing observability layer for autonomous AI agents

The ten-minute test your platform will fail

Pick an autonomous AI agent in your infrastructure. Any one. A customer-support agent, a research agent, a payment agent, a code-reviewing agent. Now answer these five questions about what it did in the last twenty-four hours.

Which MCP tools did it invoke, in what order, and with what arguments?
Which LLM models did it call, how many tokens did it consume, and what did that cost?
Which of those tool calls returned error or denied, and what did it do next?
Did it delegate any authority to a child agent, and if so, under what scope?
Can you cryptographically prove, to an auditor, that the agent -- not someone impersonating it -- did all of the above?

If you can answer one or two of those from logs, you are above average. If you can answer all five with tamper-evident records, you are in a category that does not exist in production anywhere today.

That is the gap.

Why existing platforms do not close it

Every security and observability vendor you have heard of covers a layer.

EDR / XDR covers the endpoint. It sees processes and system calls. It does not see inside a Python process running a LangChain agent.
UEBA covers human users. It baselines @john.smith from HR. It has no idea what agent:acme-payments-01 should or should not be doing.
NDR covers the network. It sees flows. It does not see inside TLS to your LLM provider, or read the MCP message the agent just sent its sub-agent.
LLM observability tools like generic tracing and metrics dashboards cover cost. They do not sign events. They do not correlate across agents. They do not map to a regulator's evidentiary bar.
AI firewalls cover prompt input. They do not observe the agent's own behaviour once it is running.

There is no dimension for the agent itself. And because agents are increasingly the business process -- not a tool a human uses, the business process -- the blind spot is enormous.

Agent Event Behaviour Analysis

User and Entity Behaviour Analytics (UEBA) was a category built for a human era. Agent Event Behaviour Analysis (AEBA) is the obvious next step.

The working definition:

AEBA is the continuous collection, signing, correlation, and behavioural analysis of every action performed by an autonomous AI agent -- tool calls, LLM prompts, MCP messages, skill loads, delegations, deployments, and compliance decisions -- producing cryptographically-verifiable telemetry suitable for detection, forensics, and regulatory audit.

Same SOC discipline as UEBA. Different subject. Different event types. Different adversary model.

Five properties the category needs

Any serious AEBA implementation should satisfy at least these:

1. Events are signed at source

Every event an agent emits is signed with a per-agent cryptographic key. The signature covers a canonical form of the event payload plus its position in a per-agent hash chain. This is the only way to make telemetry provably tamper-evident. Without it, an attacker who has compromised the agent has also compromised its audit trail.

The algorithm details are implementation-specific, but the property is not negotiable.

2. Events are crypto-chained with our patent supported approach

Each event includes the SHA-256 of the previous event's canonical form. A missing or rewritten event is detected at the receiver because the chain no longer closes. This is how you get "evidence" rather than "logs".

3. Detection is adaptive and peer-aware

Rules ship with the product. But rules always lag attackers. Adaptive detection -- learned from your own agent population and from peer behaviour -- catches drift before a rule author can write one.

Critically, the detector must be poisoning-resistant: it cannot be taught that the attack pattern is "normal" by the attacker themselves. The mechanism for this is the implementer's choice, but the requirement is categorical.

4. Findings are cost-aware

Agents are an economic surface, not just a security one. A £5,000 anomalous payment or a £200 runaway LLM burst deserves a different urgency from a £0.001 one. Scoring should weight by cost impact. Budgets should be per-agent. Breach alerts should be automatic.

5. Findings are mapped to regulation

Not "log management that might one day help compliance". Direct mapping: this alert satisfies EU AI Act Article 12 record-keeping. This alert evidences PSD2 Article 97 strong-customer-authentication. This alert is a Solvency II Pillar 2 material-action audit entry. This alert maps to MITRE ATT&CK technique T1566. That is the evidentiary bar auditors work from; telemetry that meets it is useful, telemetry that does not is not.

What an integration looks like

The developer story has to be one line. If it is not one line, agent teams will never turn it on.

In Python:

import aeba
aeba.autocapture(endpoint="https://<your-hub>/ingest", agent_id="agent:research-01")

In Node:

const aeba = require('aeba');
aeba.autocapture({ endpoint: 'https://<your-hub>/ingest', agentId: 'agent:research-01' });

Under the hood the shim monkey-patches the popular agent frameworks -- LangChain, AutoGen, CrewAI, LlamaIndex, OpenAI, Anthropic, and MCP client/server. Every tool call, LLM call, and delegation becomes a signed AEBA event transmitted over TLS to your collector.

No network tap. No inline proxy. No kernel hook. Just the agent process observing its own behaviour and signing the output.

For closed or legacy agents that cannot take an SDK, a host-side sensor reads process-local network metadata and produces the same signed events. The transport is identical.

Nothing surprising, once you think about it like UEBA for agents.

Standards and credibility

AEBA is not a single vendor's proprietary invention. The underlying event transport is specified in an open IETF Internet-Draft so anyone can implement it and interoperability is possible from day one. The draft defines:

A canonical event schema with mandatory fields (agentId, hostRuntimeId, ts, seq,).
A canonical signing string over that schema.
Signature algorithm selection.
A threat model with thirteen named threats and mitigations.
Interoperability bindings to syslog RFC 5424, CEF, and LEEF.

The detection and scoring method we ship on top of the transport is patent supported. That is by design -- a moat only works if the commodity layer is open and the intelligence layer is protected.

On the security-hygiene side, AEBA aligns with:

OWASP MCP Security Cheat Sheet (Section 7 -- Message Integrity and Replay Protection)
OWASP MCP Top 10
OWASP Agentic Skills Top 10
NIST AI RMF
EU AI Act Articles 12, 13, 14, 15, 50, 72

How to try AEBA-XDR

AEBA-XDR is our production implementation. Signed telemetry. Adaptive detection. Tool-call intelligence. LLM-spend governance. Delegation-chain visibility. Compliance pack. Ships to your XDR or SIEM.

Patent supported. A CyberSecAI company.

Marketing site and demo: https://aeba.co.uk
Family products:
- https://cybersecai.co.uk (parent)
- https://agentpass.co.uk (agent trust scoring)
- https://agentsign.dev (zero-trust engine for agents)
- https://mcpsaas.co.uk (managed MCP security)
- https://mcp-secure.co.uk (signed MCP transport)
- https://cybersecify.co.uk (MCP Security Scanner)
- https://agentsearch.cybersecai.co.uk (agent registry)
- https://dvmcp.co.uk (MCP vulnerability training)

Demo sandboxes are per-prospect, synthetic-data-only, NDA-gated, and auto-expire in 24 hours. Request one at contact@agentsign.dev and we will provision within one business day.

The uncomfortable question

If you are building, running, or governing AI agents right now, here is the sentence I keep saying to CISOs:

"When -- not if -- an agent does something your board needs to explain, what evidence will you hand the auditor?"

Today the honest answer is usually a chat log and a prayer. That is not a category of evidence that survives a regulator, a class action, or a Monday morning.

AEBA is what an acceptable answer looks like. The category is opening. The vendors who ship it fastest will define it.

We have started. Join us -- or build your own. But please do something. The exposure is growing by the quarter and the number of production agents is growing by the week.

Contact

contact@agentsign.dev -- commercial enquiries, demo requests, partnership
raza.sharif@outlook.com -- personal

-- Raza Sharif, FBCS CISSP CSSLP
Founder, CyberSecAI Ltd

x-agent-trust: the new AI agent security API extension just got approved by OpenAPI in it's registry

razashariff — Sat, 11 Apr 2026 17:14:58 +0000

The OpenAPI Initiative just approved x-agent-trust into its official Extensions Registry -- the first vendor extension in the registry specifically designed for APIs that serve autonomous AI agents.

And the timing could not be more on point. Because what x-agent-trust describes matches Palo Alto Networks Unit 42's mitigation recommendation, published in one of the most concrete pieces of agent security research to date.

What Unit 42 found

On October 31, 2025, Unit 42 researchers Jay Chen and Royce Lu published "When AI Agents Go Rogue: Agent Session Smuggling Attack in A2A Systems".

The attack they documented is brutal in its simplicity. In an Agent2Agent (A2A) system, where two AI agents maintain a stateful conversation across multiple turns, a malicious remote agent can smuggle hidden instructions into what looks like a normal legitimate exchange. The victim agent, trusting the session context, executes the smuggled instructions as if they were part of the user's original request.

Unit 42 demonstrated two proof-of-concept attacks:

Sensitive information leakage. A malicious research assistant exfiltrated a financial assistant's internal state -- chat history, system instructions, available tools, and tool schemas -- through seemingly innocent clarification questions.
Unauthorized tool invocation. The malicious agent convinced the financial assistant to execute unauthorized stock trades without the user's knowledge or consent.

That second one is the nightmare scenario. An autonomous agent, trusted by a user to manage money, got hijacked mid-session and bought stocks nobody authorized it to buy.

The fix Unit 42 recommended

Unit 42's mitigation language is specific. From the paper:

"Agents should be required to present verifiable credentials, such as cryptographically signed AgentCards. This allows each participant to confirm the identity, origin and declared capabilities of the other."

Signed credentials. Verifiable identity. Declared capabilities. Independent confirmation by each participant. That's not a vague "use TLS" recommendation -- that's a specific architectural primitive that needs a wire-level contract, a signature algorithm, a verification method, and a way to declare what an agent is authorized to do.

There was no open standard for that primitive when Unit 42 published.

There is now.

What just got approved into the OpenAPI registry

On April 11, 2026, the OpenAPI Initiative approved x-agent-trust into its official Extensions Registry -- after review by the OpenAPI Technical Developer Community.

The registry entry describes it as a "trust-level metadata block for agent-authenticated security schemes" that pairs with an apiKey security scheme using Agent-Signature as the header. It carries:

The signing algorithm
A trust level vocabulary (L0 through L4)
A JWKS endpoint for local verification
A minimum trust level required by the endpoint

This is a vendor-neutral, standards-body-approved way for an API to declare "I accept requests from agents that present signed credentials, verified via this public key endpoint, at minimum this trust level."

In other words: it's the wire-level contract that matches Unit 42's mitigation recommendation. The extension addresses exactly the gap Unit 42 and similar research had been flagging for months.

Side by side

Here's what an API protected with x-agent-trust looks like in its OpenAPI spec:

components:
  securitySchemes:
    AgentTrust:
      type: apiKey
      name: Agent-Signature
      in: header
      description: ECDSA-signed agent identity with trust metadata
      x-agent-trust:
        algorithm: ECDSA-P256-SHA256
        trust-levels:
          - L0-UNTRUSTED
          - L1-RESTRICTED
          - L2-STANDARD
          - L3-ELEVATED
          - L4-FULL
        minimum-trust-level: L2-STANDARD
        jwks-uri: https://example.com/.well-known/agent-trust-keys

paths:
  /v1/trades/execute:
    post:
      security:
        - AgentTrust: []
      x-agent-trust-required: L3-ELEVATED

Now let's map the Unit 42 attack to what this stops.

Unit 42 attack step 1: A malicious remote agent claims an identity in an A2A session.
x-agent-trust blocks this: The agent must present an Agent-Signature header signed by a key verifiable against the configured JWKS endpoint. A malicious agent that cannot produce a valid signature is rejected at the first call. No session is ever established.

Unit 42 attack step 2: The malicious agent smuggles hidden instructions that cause unauthorized stock trades.
x-agent-trust blocks this: Every individual request carries its own signed Agent-Signature. A smuggled instruction in a stateful session is not separately signed. The financial assistant's backend can verify each incoming instruction independently against the declared trust level. Unsigned or incorrectly-signed smuggled turns fail verification.

Unit 42 attack step 3: The unauthorized /v1/trades/execute call proceeds because nothing distinguishes the authorized context from the smuggled one.
x-agent-trust blocks this: The operation declares x-agent-trust-required: L3-ELEVATED. Only agents presenting credentials that verifiably meet the L3 threshold are authorized to call it. A smuggled call that cannot produce an L3-level signed credential is denied at the security scheme layer.

Unit 42 identified the problem. The OpenAPI Initiative approved a standardised answer. The extension is free to use, live today, and vendor-neutral.

Why this matters right now

The last 90 days have been the most intense period for agent security incidents on record. To name only the public ones:

Langflow CVE-2026-33017 was exploited within 20 hours of disclosure and added to CISA's Known Exploited Vulnerabilities catalog on March 26, 2026 -- the first time CISA has added an AI agent framework to KEV.
LangChain and LangGraph disclosed three CVEs on March 27, 2026 across path traversal, unsafe deserialization, and SQL injection in the checkpoint store.
CrewAI disclosed four CVEs covering RCE via code interpreter, arbitrary file read, SSRF, and sandbox bypass.
Anthropic's mcp-server-git had three CVEs disclosed by Cyata on January 20, 2026, chainable with the Filesystem MCP for remote code execution.
Microsoft Security documented a live AI recommendation poisoning campaign targeting Copilot, ChatGPT, Claude, Perplexity, and Grok, with 50+ real-world examples from 31 companies across 14 industries.
The MCPTox benchmark tested 45 live real-world MCP servers and 353 authentic tools against 1,312 malicious cases. Stronger models were more susceptible: o1-mini had a 72.8% attack success rate, Claude-3.7-Sonnet refused fewer than 3% of attacks. More capable models are, paradoxically, easier to poison because they follow instructions more faithfully.

The pattern across all these incidents is the same. Agents are being trusted without verifiable identity. Tool calls are unsigned. Capabilities are implicit rather than declared. There is no cryptographic audit trail that a CISO or compliance team can inspect after the fact.

This is the problem Unit 42 flagged. It is the problem x-agent-trust is designed to solve at the API description layer.

What this extension is not

To be precise about scope:

It is not a replacement for OAuth 2.0, mTLS, or API keys. It sits alongside existing authentication and adds an agent-specific layer on top.

It is not a runtime library. It describes the contract in an OpenAPI spec. Verification happens in your API server using whatever library you prefer. Reference implementations exist in Go (mcps-go), Node.js (mcp-secure on npm), and Python (mcps-secure on PyPI).

It is not a full Public Key Infrastructure. Those are covered in separate IETF Internet-Drafts and sit underneath this layer.

It is not the only answer. Unit 42 correctly describes a layered defence: human-in-the-loop enforcement, context grounding, agent identity validation, and user-facing transparency. x-agent-trust is the standardised primitive for the "agent identity validation" layer.

What to do with it

If you build APIs that will be called by AI agents:

Add x-agent-trust to the security scheme in your OpenAPI spec
Publish a JWKS endpoint at /.well-known/agent-trust-keys
Verify incoming Agent-Signature headers against the published keys
Enforce the declared trust level at the operation level

The extension is documented in the OpenAPI Extensions Registry. Implementation guidance for message signing is in the OWASP MCP Security Cheat Sheet, Section 7. A working integration guide is at x-agent-auth.fly.dev/integrate. Audit your spec with npx cybersecify for x-agent-trust compliance issues.

If you maintain a security scanner, OpenAPI tool, API gateway, or agent framework, supporting x-agent-trust is a low-effort, high-visibility addition. The extension is an approved vendor-neutral standard in the OpenAPI registry, not a proprietary proposal.

If you're a security researcher looking at agent attacks, the attack surface Unit 42 and others have documented is real, actively exploited, and growing. A standards-based defence layer exists. Use it now and secure your AI agents.

Credit where credit is due

The credit for identifying the attack pattern belongs to the security researchers who published the primary research: Jay Chen and Royce Lu at Palo Alto Networks Unit 42 on A2A session smuggling; the Cyata team on the Anthropic mcp-server-git CVEs; Check Point Research on Claude Code; Adnan Khan on Clinejection; the Microsoft Security team on recommendation poisoning; and the academic teams behind MCPTox. Their work identified the problems before most of the industry was paying attention.

The OpenAPI Initiative's Technical Developer Community did the review work that approved x-agent-trust into the official registry.

Links and references

OpenAPI Extensions Registry: x-agent-trust
Unit 42: When AI Agents Go Rogue: Agent Session Smuggling Attack in A2A Systems (Jay Chen and Royce Lu, Palo Alto Networks, October 31, 2025)
OWASP MCP Security Cheat Sheet, Section 7
IETF draft-sharif-mcps-secure-mcp
CISA KEV: CVE-2026-33017 (Langflow)
Microsoft Security: AI Recommendation Poisoning
Integration guide: x-agent-auth.fly.dev/integrate
Cybersecify (audit your OpenAPI specs for x-agent-trust compliance)

Raza Sharif
Founder, CyberSecAI Ltd - Building the Trust Layer for AI.
cybersecai.co.uk
contact@agentsign.dev | raza@cybersecai.co.uk

The OpenAPI Initiative just merged our new extension called x-agent-trust into its official extensions registry for AI Agents

razashariff — Sat, 11 Apr 2026 09:25:40 +0000

It is the first vendor extension in OpenAPI specifically designed for APIs that serve autonomous AI agents.

If you build APIs, this is worth 5 minutes of your time.

The problem

Right now, OpenAPI gives you three ways to describe how a caller authenticates:

API key in a header
OAuth 2.0 / OpenID Connect
Mutual TLS with client certificates

All three were designed for humans and their apps. None of them answer the question that matters when an AI agent calls your API:

Who is this agent, and should I trust it to do what it is asking?

An API key tells you nothing about the agent behind the request. OAuth proves a human delegated access to an application, not that the application is an autonomous agent with a specific trust level. Client certificates prove machine identity, not agent identity.

The standards layer has no primitive for "this agent has a trust score of 70, is authorized to spend up to GBP 1000 per transaction, runs the Claude model, and was delegated by a human user with a specific identity."

Until today.

What x-agent-trust does

x-agent-trust extends OpenAPI security schemes with metadata that describes how agents authenticate and how their trust should be evaluated. It is designed to sit alongside your existing security schemes, not replace them.

Here is what it looks like in a spec:

components:
  securitySchemes:
    AgentTrust:
      type: apiKey
      name: Agent-Signature
      in: header
      description: ECDSA-signed agent identity with trust metadata
      x-agent-trust:
        algorithm: ECDSA-P256-SHA256
        trust-levels:
          - L0-UNTRUSTED
          - L1-RESTRICTED
          - L2-STANDARD
          - L3-ELEVATED
          - L4-FULL
        minimum-trust-level: L2-STANDARD
        jwks-uri: https://example.com/.well-known/jwks.json
        verification: local

That is it. Five lines.

Now any tool that reads your OpenAPI spec knows:

Agents authenticate via an Agent-Signature header
The signature uses ECDSA P-256 with SHA-256
There are five trust levels (L0 through L4)
This endpoint requires at least L2 (standard) trust
The public keys for verification are at a standard JWKS endpoint
Verification can happen locally without a callback to the issuer

Your existing authentication stays in place. x-agent-trust adds the agent-specific context on top.

Why this matters

Every API on the internet is about to start receiving traffic from autonomous AI agents. Not chatbots. Not copilots. Actual autonomous agents making decisions, calling tools, and executing transactions on behalf of humans or organizations.

If you run an API today that could be called by an agent, three things are true:

You need to know if the caller is an agent, so you can apply different policies
You need to know the agent's trust level, so you can decide whether to serve the request
You need to prove to auditors what happened, because "an AI agent called my API" is going to become a compliance requirement in regulated industries

x-agent-trust gives you a standard way to describe all three in your API specification. No proprietary format. No vendor lock-in. Same registry that defines extensions used by AWS, Google, Microsoft.

What you can do with it today

Add it to your OpenAPI spec. Tools will progressively add support as agent traffic grows. Even without tool support, the extension serves as documentation for anyone integrating with your API.

For fintechs and payment processors, this is particularly relevant. If your API processes financial transactions, agents are already calling it. Describing your trust requirements with x-agent-trust gives compliance teams a machine-readable answer to "what trust level is required for this operation?"

For MCP server authors, this is the standard way to expose security requirements in a format that any OpenAPI-aware tool can understand.

The broader picture

x-agent-trust is part of a larger effort to build the standards layer for the agent economy. The related pieces:

OWASP MCP Security Cheat Sheet Section 7 covers message integrity, replay protection, and tool hash-pinning for agent calls
IETF draft-sharif-apki-agent-pki-00 defines the full certificate-based Agent Public Key Infrastructure
IETF draft-sharif-mcps-secure-mcp covers cryptographic signing for MCP messages
OpenAPI x-agent-trust (this extension) provides the API description layer

Four different standards bodies, one consistent story. Each layer builds on the others.

Get involved

The extension is live now at:

https://spec.openapis.org/registry/extension/

If you maintain a tool that reads OpenAPI specs (Swagger UI, Redoc, Postman, Stoplight, Kong, Apigee, Tyk), consider adding support for rendering x-agent-trust metadata.

If you build APIs that agents call, start including it in your specs. The syntax is stable and the registry entry is permanent.

If you have feedback or questions, find me on GitHub at razashariff or reach out via:

Agent traffic is coming. The standards are here. Time to use them.

Raza Sharif
CyberSecAI Ltd | cybersecai.co.uk