Tag:Security

A2A hit v1.0 this year and teams are wiring their agents to other teams' and vendors' agents. The moment your agent fetches an Agent Card and acts on it, you have extended your trust boundary to identity and code you do not control. The spec advertises auth schemes but leaves verification to you. Here is the admission gate that makes an outbound A2A call safe: verify the signed card, scope the credential you hand over, and block replays.

You pulled a skill off a registry, your agent read its instructions, and it is now ready to execute whatever code shipped in the folder. Nobody signed it, nobody diffed it, and the manifest that says "read-only" is just a text file the author wrote. Treat every third-party skill as untrusted code and put a gate in front of it: pin and hash it, check what it actually does against what it claims, and run it in a box that can only reach what it declared.

Input defenses stop bad instructions from getting in. They do nothing about what your agent says on the way out. One generated reply that leaks another customer's data or makes a promise you never authorized is a message you cannot unsend. A fail-closed egress layer that checks every output before it ships is how you keep that message from ever leaving.

An agent that holds a tool runs it with the whole application's credentials, not the current user's. That gap is the confused deputy problem, and it is how a support agent ends up refunding an order the user was never allowed to touch. The fix is a fail-closed authorization check on every side-effectful call.

The moment your agent reads untrusted content and can also call tools, a hidden instruction in a web page or email can hijack it. Here is the containment strategy that keeps a landed prompt injection from doing damage.