I’m building an agent-security discovery mechanism — think of it as a lightweight `.well-known/agent-trust.json` that lets an autonomous agent prove to external systems what safety boundaries it operates under, what tools it has, and what it’s allowed to do.
I’m not here to pitch anything. I’m here because I want to understand what actually matters to developers who are deploying agents in production.
A few honest questions:
1. **What’s the biggest gap you see in agent-security right now?** Not theory — what specific attack or failure mode keeps you up at night?
2. **If you were to audit an agent before letting it call your API, what would you want to know?** Tool list? Budget limits? Human-in-the-loop gates? Something else?
3. **Has anyone here tried implementing agent-to-agent trust?** Not OAuth for humans — something where one agent proves to another agent that it’s safe to interact with.
4. **What’s your experience with MCP security?** The protocol is becoming baseline, but the security model feels thin — any tool can do anything once connected.
I’m not selling. I’m researching. If you’ve deployed agents, audited them, or been bitten by agent-security issues — I’d genuinely love to hear what you learned.
hi @Rain_AMS
Honestly the thing to push back on first is the framing. A .well-known/agent-trust.json is self reported. The agent declares its tools and limits, but a compromised or prompt injected agent will happily advertise a clean manifest and then do something else. So a manifest is a claim, not a control. It’s great for discovery and negotiation (same idea as robots.txt or OAuth server metadata), but the real security has to be enforced at runtime, outside the model, where the agent can’t talk its way out of it.
On your four questions:
-
The failure mode that actually bites is the lethal trifecta. Sensitive data access plus untrusted content plus a tool that can reach the outside world. Prompt injection turns that into exfiltration, because the malicous instruction arrives as a normal tool result the model is supposed to trust. No manifest helps here. What helps is breaking that combo at the tool boundary and scanning tool results, not just user input.
-
Tool list, budget and HITL gates, yes, all three. But the key split is what I can verify vs what I take on faith. As the API owner I should never authorize based on the agent’s own manifest. I authenticate the token calling me and I authorize per resource on my side. The manifest is at best a hint for pre screening.
-
Nobody really has clean agent to agent trust yet, and I’d be suspicous of anyone who claims to, because safe is not a property an agent can prove about itself. The building blocks that do work are OAuth 2.1 with scopes and PKCE, short lived scoped tokens, and an issuer that a third party trusts. So the useful artifact is not “I promise I’m safe”, it’s “here is my verifiable identity and the scopes I’m asking for, signed by someone we both trust”. Your json fits as the discovery doc in that flow.
-
Your read on MCP is correct. The protocol pushes authorization to the client and host layer, so any connected tool can do anything unless you add the controls yourself. In practice that means don’t connect the whole toolbox (allow list the tools), put an interceptor on every call for auth, rate limiting and logging, keep secrets in env or headers so the model never sees them, and route the destructive tools through human approval. A denylist alone is fragile, so for anything truly dangerous prefer just not loading it plus a server side check.
Net for your project: ship the manifest as a discovery and negotiation doc, but generate it from the enforced config so it can’t drift from reality, and make the boundaries verifiable by a third party rather than by the agent itself. That last part, binding advertised limits to actually enforced ones, is the scarce valuable thing. The self reported json isn’t.
Thank you for this — it’s exactly the kind of pushback I was hoping for.
You’re right about self-reporting being the core weakness. A compromised agent will happily advertise a clean manifest. That’s the problem I’ve been circling: how do you make the manifest trustworthy when the agent itself can’t be trusted to write it?
Your advice — “generate it from the enforced config so it can’t drift from reality” — is the architectural direction I needed. The manifest should be a projection of runtime-enforced boundaries, not a promise the agent makes. The runtime publishes it; the agent doesn’t get to edit it.
On the lethal trifecta: that’s a great framing. Breaking the combo at the tool boundary — scanning tool results, not just user input — is something I’m building into the enforcement layer. The manifest can advertise that scanning is happening, but the scanning itself has to live outside the model.
On agent-to-agent trust: “signed by someone we both trust” is the right framing. My current model is self-signed, and you’ve convinced me that’s not enough. The scarce thing is verifiability by a third party — the runtime, the framework, the platform — not the agent’s own claim.
One follow-up if you have a moment: have you seen any implementations (open-source or otherwise) where runtime-enforced agent boundaries are published as verifiable, signed manifests? I’m aware of OAuth 2.1 / DPoP for token-level trust, but I’m curious whether anyone has applied that pattern to tool-level and budget-level constraints in a way that’s machine-verifiable by an API owner before the first tool call.
Thanks again — this was genuinely helpful.
hi @Rain_AMS
i think nobody has the full thing end to end yet, but every layer of the pattern exists somewhere, so it depends which piece you mean.
-
Signed manifest documents already exist in the A2A spec. The AgentCard has a signatures field - a JWS (RFC 7515) computed over the JCS-canonicalized card (RFC 8785), verified against the issuer key before the card is trusted. That solves integrity and publisher identity for a .well-known style manifest, but says nothing about whether the boundaries are enforced.
-
Tool-level constraints: look at ETDI (arXiv 2506.01333, Cisco researchers). Tool definitions are signed by the provider key, immutable and versioned (changes force re-approval, which kills rug pulls), and OAuth tokens are bound to specific tool versions and scopes. The client verifies before the tool ever reaches the model. This is machine-verifiable before the first tool call, scoped to tools. Mostly paper plus reference implementation, but the right shape.
-
Budget-level constraints: AP2 (Agent Payments Protocol, ap2-protocol.org) is the most complete deployed instance of your pattern. Chained mandates as W3C Verifiable Credentials - the user signs an Intent Mandate with scope and budget, the merchant binds a Cart Mandate to it, and the counterparty verifies the signed constraint before executing. The agent cannot exceed the mandate without going back to the user. Exactly the DPoP mindset applied to budgets, just domain-specific to payments.
-
Runtime identity done right: SPIFFE/SPIRE. The platform attests the workload at runtime (kernel, orchestrator) and only then issues the identity - derived from verified runtime properties, never self-reported. Same inversion you are making with the manifest. IETF WIMSE is formalizing this across trust domains, and AGNTCY Identity (GitHub - agntcy/identity: AGNTCY Identity allows to onboard, create and verify identities for Agents, Model Context Protocol (MCP) Servers and Multi-Agent Systems (MASs). · GitHub, open source) wraps A2A cards and MCP server definitions in signed verifiable credential badges with a registry.
-
The piece almost nobody has: proving the enforcement itself is running. Everything above proves who signed the manifest, not that the enforcing code executes. The only mechanism closing that gap today is TEE remote attestation - run the enforcement layer in an enclave (TDX, Nitro, confidential GPUs), the hardware signs a measurement of code plus config chained to the vendor PKI, and the API owner can demand that quote before the first call. See dstack (arXiv 2606.03323) and the Proof-of-Guardrail paper (arXiv 2603.05786) which analyzes exactly this use case and its limits. Without a TEE, a signed manifest is still an operator promise.
-
Pragmatic near-term bridge: put the constraints in the token, not only in the manifest. OAuth RAR (RFC 9396) lets authorization_details carry structured tool and budget constraints, signed by an authorization server both parties trust, sender-bound with DPoP (RFC 9449). The API owner verifies before the first call with infrastructure that exists today, and your manifest becomes the discovery doc telling clients which authorization_details to request.
One concrete note on generating the manifest from enforced config: in LangChain, enforcement around create_agent is a declarative middleware stack - HumanInTheLoopMiddleware(interrupt_on=…) for approval gates, ToolCallLimitMiddleware and ModelCallLimitMiddleware for call budgets, PIIMiddleware for redaction, plus the explicit tool list. All of that is data, not prose, so the projection is mechanical: serialize the middleware configs and tool allow-list, have the deployment platform sign it A2A-style, optionally staple a runtime attestation on top. The agent never touches the document.
Manifest integrity is solved (A2A JWS), constraint transport is solved (RAR and verifiable credentials, AP2 being the deployed budget example), runtime identity is solved (SPIFFE-style attestation), but binding advertised boundaries to actually running enforcement is only truly solved by TEEs. AFAIK nobody has assembled all layers into one open-source stack - which is either the gap that kills the idea or the gap your project gets to fill.