DEV Community

razashariff
razashariff

Posted on

Why AI Agents Need Zero Trust Identity (and How to Build It)

#ai #opensource #security #showdev

Two weeks ago, OpenAI acquired Promptfoo -- an AI security testing company -- to bolster their enterprise agent platform. Around the same time, GitHub announced agentic AI features that let agents write, review, and merge code autonomously.

The pattern is obvious: agents are graduating from "chatbots that answer questions" to "autonomous systems that do things." They call APIs, access databases, deploy code, and spend money. And the industry is scrambling to figure out how to secure them.

Here is the part nobody is talking about: agents have no identity.

The Problem

When a human developer accesses your production database, you know who they are. They authenticated with SSO, passed MFA, and there is an audit trail of every query they ran. If they go rogue, you revoke their access.

When an AI agent accesses your production database, what do you know? You know it has an API key. That is it. You don't know:

  • Which agent is using that key (or if it is even the agent you think it is)
  • What the agent did with the data it accessed
  • Whether its code has been tampered with since you last reviewed it
  • Its behavioral history -- has it been reliable, or has it been making suspicious calls?
  • How to revoke it without breaking every other agent sharing that key

API keys are shared secrets. OAuth was designed for humans delegating access to apps. mTLS verifies connections, not agent identity. None of these were built for the world we are entering -- one where hundreds of autonomous agents operate across your infrastructure, each needing its own identity, its own trust score, and its own audit trail.

What Zero Trust for Agents Actually Looks Like

I built AgentSign to solve this. It is an open-source zero trust engine with five subsystems, each addressing a specific gap in current agent security.

1. Identity Pipeline

Every agent starts untrusted and earns its way to production through a cryptographically recorded pipeline:

INTAKE -> VETTING -> TESTING -> DEV_APPROVED -> PROD_APPROVED -> ACTIVE
Enter fullscreen mode Exit fullscreen mode

Each stage gate is signed. You can not skip stages. The pipeline records who approved each transition and when. If an agent's code changes, its code attestation hash changes, and its trust score reflects that.

This is not a permissions list. It is a verifiable history of how an agent earned its access.

2. Agent Passport

Every agent gets a self-contained signed JSON document -- its passport. The passport includes the agent's identity, code hash, trust score, pipeline stage, and a cryptographic signature over all of it.

const passport = await agent.getPassport();
// {
//   agent_id: "agent_59b778afe924",
//   name: "Procurement Bot",
//   code_hash: "a1b2c3d4...",
//   trust_score: 85,
//   pipeline_stage: "ACTIVE",
//   signature: "3045...",
//   issued_at: "2026-03-10T14:22:00Z"
// }
Enter fullscreen mode Exit fullscreen mode

The key property: passports work offline. Any system can verify an agent's identity without calling a central server. The passport is self-verifying. This matters in air-gapped environments, edge deployments, and anywhere you don't want a single point of failure.

3. Execution Chains

Every input/output pair the agent processes is signed and chained into a tamper-proof DAG:

const signed = agent.sign(
  { query: 'SELECT * FROM orders WHERE total > 10000' },  // input
  { rows: 47, columns: ['id', 'customer', 'total'] }       // output
);

// signed.executionHash -> "7d44fab5..."
// signed.signature     -> "3045..."
// signed.verified      -> true
Enter fullscreen mode Exit fullscreen mode

Change one byte of the input or output after signing, and verification fails:

agent.verifyOutput({ rows: 48, columns: ['id', 'customer', 'total'] }, signed);
// -> 'TAMPERED'
Enter fullscreen mode Exit fullscreen mode

This is not logging. This is cryptographic proof of what the agent did. Useful for compliance, incident investigation, and building trust over time.

4. MCP Trust Layer

This is the feature I am most interested in feedback on. The Model Context Protocol (MCP) is becoming the standard way agents access tools -- databases, APIs, file systems, deployment pipelines. But MCP has no built-in identity or trust verification. Any agent with the right connection string can call any tool.

AgentSign sits between agents and MCP servers. Before an agent can use any tool, it presents its passport. AgentSign checks identity, trust score, and pipeline stage, then returns ALLOW or DENY:

// Inside your MCP server -- add 4 lines
app.post('/tools/query', async (req, res) => {
  const gate = await fetch('http://agentsign:8888/api/mcp/verify', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      agent_id: req.headers['x-agent-id'],
      mcp_server_id: 'database-mcp',
      tool_name: 'query'
    })
  });
  const { decision, trust_score, checks_passed } = await gate.json();

  if (decision !== 'ALLOW') {
    return res.status(403).json({ error: 'Trust gate denied' });
  }

  // Agent verified -- execute the tool
  // ...
});
Enter fullscreen mode Exit fullscreen mode

Or from the SDK side:

const gate = await agent.verifyMCP('database-mcp', 'query_users');
// { decision: 'ALLOW', trust_score: 85, checks_passed: ['identity', 'trust', 'pipeline'] }
Enter fullscreen mode Exit fullscreen mode

This is the missing layer. Not "can this agent connect?" but "should this agent be trusted to use this specific tool right now?"

5. Trust Scoring

Every agent has a trust score from 0 to 100, computed from:

  • Code attestation -- has the agent's code been reviewed and signed?
  • Pipeline stage -- ACTIVE agents score higher than INTAKE agents
  • Execution history -- success rate, consistency, no anomalies
  • Swarm membership -- if one agent in a group is revoked, the group's scores are affected

The score is not static. It changes based on behavior. An agent that consistently produces verified outputs builds trust. An agent that starts failing or acting erratically loses it.

Get Started in 5 Lines 

npm install agentsign
Enter fullscreen mode Exit fullscreen mode 
const AgentSign = require('agentsign');
const agent = new AgentSign({ serverUrl: 'http://localhost:8888' });

await agent.register({ name: 'My Agent', category: 'automation' });
await agent.advanceToActive();
const passport = await agent.getPassport();
Enter fullscreen mode Exit fullscreen mode

Zero runtime dependencies. Node 18+. The SDK uses only Node's built-in crypto module.

For local development, you don't need the server for signing -- the SDK generates HMAC-SHA256 keys locally at ~/.agentsign/keys/:

// Local signing -- zero network calls
const signed = agent.sign(
  { task: 'summarize document' },
  { summary: '...' }
);
agent.verify(signed); // true
Enter fullscreen mode Exit fullscreen mode

Try It Right Now -- No Install Needed

I put together a Colab notebook that walks through the full lifecycle: register an agent, advance it through the pipeline, get its passport, sign executions, and verify them.

Open the Colab notebook -- takes about 60 seconds. Click "Run All" and watch an agent go from INTAKE to ACTIVE with a cryptographic passport.

Self-Hosting the Server

The AgentSign engine runs entirely on your infrastructure. Nothing phones home.

# Docker
docker run -d -p 8888:8888 -v agentsign-data:/app/data ghcr.io/razashariff/agentsign:latest

# Kubernetes
helm install agentsign ./deploy/helm/agentsign \
  --set signer=aws-kms \
  --set aws.keyId=arn:aws:kms:eu-west-2:123:key/abc
Enter fullscreen mode Exit fullscreen mode

The server is FastAPI + SQLite. Data persists via the Docker volume. The web dashboard runs on port 8888 -- it gives you a live view of agents, pipeline stages, trust scores, MCP verifications, and execution chains.

HSM and Cloud KMS Support

The default signer is file-based HMAC-SHA256, which is fine for development and small deployments. For production, AgentSign supports hardware security modules and cloud key management:

Signer Install Use Case
File (default) -- Dev, testing, small deployments
PKCS#11 npm i pkcs11js Thales, SafeNet, YubiHSM, SoftHSM
AWS KMS npm i @aws-sdk/client-kms AWS / CloudHSM
Azure Key Vault npm i @azure/keyvault-keys @azure/identity Azure
GCP Cloud KMS npm i @google-cloud/kms Google Cloud
HashiCorp Vault -- (native fetch) Vault Transit engine

All cloud signers are optional peer dependencies. You only install what you use:

const agent = new AgentSign({
  serverUrl: 'https://agentsign.internal:8888',
  signer: 'aws-kms',
  aws: { keyId: 'arn:aws:kms:eu-west-2:123:key/abc-def', region: 'eu-west-2' },
});

const signed = await agent.signAsync(input, output); // async for cloud signers
Enter fullscreen mode Exit fullscreen mode

How AgentSign Compares

AgentSign API Keys OAuth 2.0 mTLS
Agent identity Cryptographic passport (self-contained, offline) Shared secret Token (human-centric) Certificate (connection only)
Execution audit Signed input/output chain (DAG) Nothing Nothing Nothing
Tamper detection SHA-256 hash chain None None None
Trust scoring 0-100 behavioral, dynamic None Scopes (static) None
Offline verification Yes (passport is self-verifying) No No Partial
Swarm revocation Instant (all agents in a group) Manual, per-key Manual CRL propagation lag
MCP integration Native Trust Gate None None None
Designed for AI agents Humans/services Humans/apps Service mesh

The core difference: existing approaches verify connections. AgentSign verifies agents -- their identity, their behavior, their history, and what they did with the access they were given.

Why Open Source

AgentSign is MIT licensed. The SDK has zero runtime dependencies. The server runs on your infrastructure with your keys. There is no SaaS, no telemetry, no vendor lock-in.

The reasoning is straightforward: a trust layer that you can not inspect is not trustworthy. If you are going to stake your infrastructure security on something, you should be able to read every line of code, audit the cryptography, and run it in an air-gapped network if you want to.

The patent (GB2604808.2, filed March 2026 at UKIPO) covers the combination of the five subsystems -- the identity pipeline, passports, execution chains, MCP trust layer, and trust scoring working together. The code itself is MIT. Use it, fork it, extend it.

What's Next

A few things on the roadmap:

  • Python SDK -- same API surface as the Node SDK
  • Agent-to-agent verification -- agents presenting passports to each other, not just to MCP servers
  • Trust federation -- organizations sharing agent trust scores across boundaries
  • Payment Trust Gate -- agents with wallets, spending limits, and merchant whitelists (already built in the server, SDK support coming)

Links

If you are building with autonomous agents -- or worried about securing them -- I would genuinely appreciate feedback. Star the repo if the problem resonates. Open an issue if you see a gap. Or just run the Colab and tell me what you think.

Built by CyberSecAI. Patent Pending (GB2604808.2).

Top comments (0)