DEV Community: razashariff

Zero-cost, Zero Trust AI: secure agents on local Qwen with MCPS

razashariff — Tue, 26 May 2026 14:29:02 +0000

Run a AI agents on free, local Qwen, keep every byte on your own hardware, and prove cryptographically what it did. Signer and verifier included. For AI builders and architects.

By the end of this you will have an AI agent that costs nothing per token, never sends a byte off your own hardware, and can prove -- cryptographically -- exactly what it did and that no one tampered with it. Signer and verifier, both included. About fifteen lines of code.

As a 30 Year Security Leadership and Breach prevention we reogised thee issue of adoption with Local hosted models and the security concerns thats validated lack of adoption.

We have changed this mindset with our stack - Meet MCPS and Local LLMs on your hosting.

That is the whole promise. Let me earn it.

The question your architects keep asking

Where does your prompt actually go?

With a hosted model API, the honest answer is: across your trust boundary, on every single call. Your prompts, your customers' data, your internal context -- all of it leaves the building and lands inside someone else's tenancy. For a regulated team, that one sentence is the difference between a green light and a twelve-week security review.

And the cost is no longer hypothetical. In May 2026 Microsoft began cancelling its internal Claude Code licenses, moving staff to Copilot CLI by June 30. The reported reason was not quality -- engineers liked the tool. It was that token-based billing burned through the annual AI budget in months; flat seat pricing had hidden the true per-token spend (Windows Central).

If Microsoft cannot predict its metered AI bill, neither can you.

There is another way to build, and it has gotten very good.

Free brain, signed hands

Here is the one idea this whole article turns on: free brain, signed hands.

The LLM AI brain is a free, open model -- Qwen -- running locally. It costs nothing per token and it runs on your machine or sever. The hands are the tool calls the agent makes, and every one of them is cryptographically signed, identity-bound, and replay-proof, with a verifier you run on your side of the wire.

The half that local models do not give you -

Running a model locally solves privacy. It does not solve integrity or identity.

A local agent that calls tools is still, by default, anonymous and unsigned. Nothing proves which agent made a call. Nothing stops a captured request being replayed. Nothing detects a tampered argument before it hits your database. You have moved the brain in-house and left the hands bare.

This is the fence I want to build around the approach, because it is exactly where most "run it locally" guides stop. Local privacy without per-call integrity is half a security model.

So we built the other half. MCPS is the security layer we wrote for the Model Context Protocol -- think of it as the secure version of MCP. It signs every tool call with a P-256 key, binds it to a verifiable agent identity (AgentPass), and rejects anything unsigned, tampered, or replayed. The design is published as an IETF Internet-Draft, draft-sharif-mcps-secure-mcp.

Currenty integrated in US based FinTech organisation's with live production.

The MCP ecosystem is enormous -- the official SDKs have been downloaded hundreds of millions of times -- and almost none of that traffic is signed. That is the gap.

We checked that the data really stays local.

Claims about "your data never leaves" should be demonstrated, not asserted. So before writing a word of this, We watched what the model actually talks to.

While Qwen generated a few thousand characters of output, We sampled every network connection the Ollama process held:

# run this during a real inference
lsof -nP -iTCP -a -c ollama | grep ESTABLISHED

Every endpoint was 127.0.0.1 -- loopback. The client, and the model's own internal runner, talking to themselves. Ollama was bound to 127.0.0.1 only: not exposed to the LAN, let alone the internet. Zero external connections. The prompt never left the machine.

You do not have to trust our screenshot. Here is the acid test, and it takes ten seconds:

Turn off Wi-Fi. Run the same prompt. It still answers.

If it works with no network, it provably needs none. That is a sentence you can put in front of an auditor.

It maps to the standards your reviewers cite

This is not a hobby setup. The architecture lines up with the guidance security teams are already being measured against:

Concern	Where it is covered
MCP tool-call integrity, identity, replay	OWASP MCP Security Cheat Sheet
AI agent verification controls (C10)	OWASP AISVS
MCP security design considerations	NSA MCP guidance, May 2026
Data residency / sovereignty	model + tools run on-premise or in your own cloud; no third-party processor

The NSA put MCP security design in writing in May 2026. Signing tool calls is no longer a nice-to-have you have to justify -- it is the direction the guidance is already pointing.

Build it in three steps

All free. All local. Signer and verifier both yours.

1. Run a free model locally. Qwen via Ollama, OpenAI-compatible, fully offline.

ollama pull qwen3:14b
ollama serve

2. The agent signs. The SDK gives the agent an AgentPass identity and MCPS-signs every tool call. It runs on stock Qwen-Agent -- no fork, just a runtime hook.

from secure_qwen import SecureQwenAgent

agent = SecureQwenAgent(
    model="qwen3:14b",
    mcp_servers={"tools": {"command": "python", "args": ["server.py"]}},
)
for msg in agent.run("add 17 and 25 with secure_add"):
    print(msg)

3. The verifier enforces. One line wraps your MCP server. Unsigned, tampered, or replayed calls are rejected at the gate, before they reach your tools or data.

from mcp_secure import secure_mcp

secure_mcp(server)   # signature + identity + replay checked here. fail-closed.

Want DeepSeek instead of Qwen? Same code, swap one line: model="deepseek-r1:14b". The security layer is model-agnostic on purpose -- it does not care which free brain you bolt the signed hands onto.

Verify what you downloaded

Supply-chain integrity cuts both ways: a security tool you cannot verify is just another dependency to worry about. Every release ships a signed hash manifest, so you can check it before you run a line of it:

# integrity: do the files match the manifest?
shasum -a 256 -c SHA256SUMS

# authenticity: was the manifest signed by our release key?
openssl dgst -sha256 -verify release-pubkey.pem -signature SHA256SUMS.sig SHA256SUMS

P-256 ECDSA, the same primitive MCPS uses on the wire. If either check fails, do not run it.

What it actually costs

Nothing, per token. You pay for hardware and electricity once, and then a million calls cost the same as one. There is no meter, no surprise invoice at the end of the quarter, and no budget that quietly evaporates because a few agents got chatty. That is the lesson buried in the Microsoft story: the problem was never the model, it was the metering.

Local inference turns a variable, unpredictable operating cost into a fixed, owned capability.

Build on Qwen. Build secure. Build to comply.

That is the contribution I want to leave you with. A free model gives you economics and privacy. MCPS and AgentPass give you the integrity and identity that local models leave bare. Together they are a stack you can run on your own hardware, prove to an auditor, and never hand to a third party.

Signer and verifier, both yours. Free brain, signed hands.

Read the architecture and the standards mapping: agentpass.co.uk/qwen-builders
The protocol: MCPS Internet-Draft
The identity layer: AgentPass

Want to build now? The SDK, the verifier, and the signed manifest are ready. Contact us at contact@agentsign.dev and we will get you running on secure local Qwen today.

The SDK is licensed BUSL-1.1: free to run, self-host, and modify; not for resale. It converts to Apache 2.0 in 2030.

The NSA just published an MCP security playbook. We created Agent Trust Transport Protocol ATTP - Implement today with MCPS

razashariff — Sat, 23 May 2026 18:26:54 +0000

In May 2026 the United States National Security Agency published a Cybersecurity Information notice titled Model Context Protocol (MCP): Security Design Considerations
for AI-Driven Automation (document ID U/OO/6030316-26 / PP-26-1834). It is fifteen pages on what the NSA considers the minimum security baseline for any production MCPdeployment.

If you are building anything on MCP, server, client, gateway, orchestrator, framework, or agent runtime, read it. Then read this, because the standards work the NSA describes already exists, and you can integrate it today.

What the NSA called out

Four operational requirements run through the document.

Cryptographically sign and verify MCP messages

Quoting the NSA directly (page 12): "the standard can be extended with cryptographic signatures directly within the JSON payload ... MCP messages should include expiration timestamps and replay protection metadata ... cryptographically bind requests to time and context to prevent tampering, intentional replay techniques, and
unintended re-execution."

Translation: TLS is not enough. The MCP payload itself needs an envelope with a signature, a nonce, a timestamp, and a freshness window.

Cryptographic identity for agents (not bearer tokens)

Page 4: MCP "lacks support for exchanging Role Based Access Control permissions at instantiation." Bearer tokens can be lifted, replayed, and impersonated. Agents need
verifiable cryptographic identity, bound to scope, trust level, and issuer.

Structured audit logging with cryptographic integrity

Page 12 to 13: log every tool invocation, every parameter, every result, with cryptographic hashes, so an XDR or SIEM can reconstruct exactly what happened and prove it
has not been altered.

Track MCP-specific CVEs and patch them

Page 13: build a vulnerability-monitoring process around your MCP package surface, the same as you would for any other production dependency.

What already exists, today

Here is the awkward bit, depending on where you sit: every single one of these four requirements has an open specification, a reference implementation, and at least one
production integration. They predate the NSA notice.

MCPS, the cryptographic signing layer for MCP

draft-sharif-mcps-secure-mcp on the IETF Datatracker since March 2026. Four primitives:

Agent Passports. Cryptographic identity bound to a specific origin.
Signed message envelopes. ECDSA P-256 over a canonical-signing-string, with timestamp and nonce, for integrity and non-repudiation.
Tool definition signatures. Covering the full tool object, so a downstream client can detect tool poisoning or schema tampering.
Nonce plus timestamp replay protection with transcript binding, to prevent downgrade attacks.

The wire format is JSON-on-the-wire, signing-string-canonical, and stays inside the MCP message body. No transport changes, no protocol fork.

ATTP, agent-trust transport above MCPS

draft-sharif-attp, live since 1 May 2026. Where MCPS does message-level signing for MCP, ATTP defines a protocol-agnostic trust transport above it: five hierarchical
trust levels (L0 to L4), action-limit enforcement, compliance gating, and tamper-evident audit. It maps onto MCP, REST, Google A2A, gRPC, and GraphQL.

Live demo with real ECDSA P-256 in the browser, including tamper and strip-ATTP buttons:
👉 https://attp.cybersecai.co.uk

AgentPass, the identity / RBAC layer the NSA describes

L0 to L4 trust grades, OFAC and HMT sanctions screening (75,784 entries baked in), graduated spend limits, hash-chained audit trails, agent-to-agent payment
authorisation, optional Mastercard risk integration.

👉 https://agentpass.co.uk

The Go SDK (agentpass-go) verifies agent identity certificates with zero network calls. Pure local crypto, standard library only, no CGo. Trust anchors load like TLS
root CAs.

x-agent-trust, agent trust as a first-class OpenAPI declaration

Merged into the official OpenAPI Initiative Extension Registry on 11 April 2026, approved by Henry Andrews and Mike Kistler (Microsoft):
👉 https://spec.openapis.org/registry/extension/x-agent-trust.html

components:
securitySchemes:
AgentTrust:
type: apiKey
description: Uses agent trust information in lieu of a traditional API key. Requires the x-agent-trust extension.
in: header
name: Agent-Signature
x-agent-trust:
algorithm: ES256
trustLevels: [L0, L1, L2, L3, L4]
issuerKeysUrl: /.well-known/agent-trust-keys
security:
- AgentTrust: [L3]

Any OpenAPI-described service can now declare which agent trust level is required to call which operation. Tooling that understands the extension can verify the
Agent-Signature header before the request even reaches application code.

OWASP MCP Security Cheat Sheet, Section 7

Section 7, Message-Level Integrity and Replay Protection contributed via PR #2065, merged 26 March 2026. The cheat sheet now documents the patterns the NSA later
described, including signing JSON-RPC messages with asymmetric keys, including nonces and timestamps, and pinning tool definitions using hashes.

OWASP AISVS 1.0, Chapter C10

An entire chapter on MCP Security, with verifiable requirements at L1 to L3. Two requirements map directly to the MCPS spec:

10.2.11 (L2). Agents authenticate using cryptographically bound identity credentials rather than bearer-only tokens, ensuring agent identity cannot be transferred, replayed, or impersonated.
10.4.10 (L3). MCP servers sign tool responses with a unique nonce and timestamp within a bounded time window, so the calling agent can verify origin, integrity, and freshness, preventing spoofing, tampering, and replay.

CVE-2026-39313, and five more on the clock

CVE-2026-39313. Unbounded-memory-allocation vulnerability in mcp-framework (CWE-770, High), assigned and published 16 April 2026.

Five further CVE submissions, across ~57M weekly downloads of MCP packages (including the official MCP TypeScript and Python SDKs), are under coordinated-disclosure clock.

This is the NSA's recommendation #4 in action. The package surface is being audited, and the gaps are being closed.

In production, today

moov-io / watchman (Apache 2.0, ~460 stars). Sanctions screening used by SEC-registered transfer agents and BaaS platforms. MCPS and AgentPass are merged into main. The production deployment guide ships an AgentPass configuration block:

AgentPass:
TrustAnchorPath: /etc/watchman/agentpass-ca.pem
MinTrustLevel: 2
RequiredScopes:
- sanctions:search

👉 https://github.com/moov-io/watchman/blob/master/docs/mcp.md

Cisco AI Defense. Cisco's commercial agent-security product ships our MCPS protocol as part of its agent-defence stack.
👉 https://www.cisco.com/site/us/en/products/security/ai-defense/index.html

Kong API Gateway. A plugin that turns every API behind Kong into an MCPS-signed endpoint with zero developer effort. Available to design partners under NDA.

AEBA-XDR, runtime behaviour analysis for every agent. Anomaly detection in milliseconds. Eight behavioural dimensions, every agent cryptographically identified,
hash-chained tamper-evident audit, native forwarders for major XDR and SIEM platforms via CEF, LEEF and syslog RFC 5424. Free evaluation tier for up to three agents.
👉 https://aeba.co.uk

What to do this week

If you ship MCP in production:

Pin MCP-package versions and subscribe to CVE feeds for every MCP-related dependency. Start with CVE-2026-39313.
Add MCPS message signing to your most-sensitive tool invocations. The spec is small enough to implement from draft-sharif-mcps-secure-mcp in a sprint.
Declare your agent-trust requirements in your OpenAPI document using x-agent-trust. Whether or not your runtime enforces them yet, you have made the requirement machine-readable for everything downstream.
Wire your tool invocations into a tamper-evident audit log that maps to the AISVS C10 controls.
Read the NSA notice. If you skim only one document on MCP security this quarter, skim that one.

The standard exists. The reference code exists. The integrations exist. The CVE feed exists.

The protocol can be secured. Now there is no reason not to.

Raza Sharif (FBCS, CISSP, CSSLP)
Founder, CyberSecAI Ltd

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