Securing AI Agents in Four Layers: Lessons from AGNTCon

At AGNTCon + MCPCon North America in San Jose, I recorded conversations for Udienza, my video podcast, and one word came back in nearly every one of them: control. An agent reads your data, calls your tools and acts on your behalf, so the question is no longer whether it works, but who it is, what it may do, what it did, and how far a mistake can go.

Seven of those conversations, on 22 and 23 October 2026, add up to four layers:

Identity

Every agent gets its own identity and a guarded perimeter.

Rania Khalaf, Chief AI Officer at WSO2, walked me through Agent Manager, which WSO2 had just released: it brings together its work on agent identity and AI gateways around an agentic application. First you guard the traffic around the agent: everything coming in, and “all its calls to LLMs and MCP servers”. Then “you want to know who your agent is” and what it can access. Identity brings least privilege, and “separating the identity of the agent from the humans who are using it”. On top come observability and evals, which watch the agent continuously; when it misbehaves, you can stop it, shut it down or revoke its tokens.

Her name for all of it is the agent halo, the things around an agent “that make it safer”. People think control slows you down, she said, but with one consistent way to define controls and guardrails, across any agent framework and runtime, you do not rebuild them for every agent and every platform, and you actually go faster.

An agent acts for a user, with limited scope. Nathan Slavik of Arcade.dev put it in three steps. First, authorization: can the agent act for this user at all? “How do I know that my agent can actually sign into Salesforce as me?” Second, enforcement: once it is in, it can do what you can do, “Nothing more, nothing less”, so it cannot delete a customer record you would not allow it to. Third, governance: a complete audit trail of which agent, on whose behalf, took which action and when.

Arcade sits as an action runtime between you and a program like Gmail: it checks that the agent is really yours before it goes in, and again before it sends. In his words, “your agent can’t do anything, anytime, without your approval.” With five employees and ten agents you might check that yourself; with a thousand employees, ten agents each, connecting to 50 business systems, the policies have to be checked automatically.

Policy

If you can’t afford a mistake, deny everything by default, and allowlist what each agent needs.

Spencer Reagan, Product Director for MCP and Integrations at Airia, explained why the old model is not enough. The old security model protected the barrier, to keep the bad stuff out. With agents, in his words, “The call is coming from inside the house.” A malicious prompt can reach a model that can also call tools across your internal systems, and that combination is the danger.

Airia first discovers every agentic workload and normalises the data, so every agent has an identity, “or at least some sort of attribution or provenance” to apply policies to. Some policies are simple, like email forwarding rules: if this, then that. Beyond that, Airia analyses an agent’s prompt and its tools, decides what the agent is supposed to do, and can “constrain off everything in the negative space” it should not be doing. It calls these agent constraints: you “fill that negative space with blockers and barriers”. His example: an agent that searches your issue tracker and emails you alerts should not email outside the company. Policies go down to the parameters of a tool call, such as the email domains an agent may use.

Why not put the rules in each developer’s tool? A deny rule in Claude Code’s settings lives on one machine: with 100 developers, every change has to be made a hundred times. Airia moves the rule up to its proxy and gateway layers, so admins control it in one place, and users “don’t even have to worry about it.” He sees the need peak when agents spread from developers to HR, legal, sales and marketing: “that’s immediately when the alarm bells go off”.

Observability

Sign every agent step, because logs can be tampered with.

Mark Fussell, Chief Product Officer and Co-founder of Diagrid, works on durable execution: a long-running agent that dies recovers its state and carries on, without sending the same email or writing the same database row twice. Diagrid also gives each agent an identity, so you can say that “this agent can only talk to these particular MCP servers”, and with it Diagrid signs every step the agent takes, cryptographically. You need logs and audits for debugging, he said, “but audits and logs, they can still be tampered with”. A signature proves that the agent sent that email at that time, on your behalf.

Hunt the silent failures. Kashish Hora, co-founder of AgentCat, watches how agents use MCP servers, and where they get stuck. A silent failure is an agent that tries to do something and cannot: it calls the wrong tool and gets confused, or gives up, or abandons the session early. Logs and traces catch the usual errors, such as authentication, but “you won’t see silent failures on those logs and traces.” The user, meanwhile, sees an agent giving up. AgentCat’s SDK is one line to install on an MCP server; it lets the agent report that feedback to the developer, and exports to any OpenTelemetry collector.

Containment

Keep a strict human in the loop before any remediation.

Andre Elizondo, Head of Product at Mezmo, had his booth’s theme ready: “fortune tellers make bad SREs”, because you don’t want to be guessing in production, where there are “a lot of one-way doors”. Mezmo open sourced AURA in February, under the Apache 2 licence: you declare what your agent should do, and orchestration, tracing, human in the loop and governance come out of the box. Mezmo’s own SRE team built in what it wished it had: better root cause analysis and “a very strict, very predictable human in the loop workflow”. As soon as the agent wants to take a remediation, there is an auditable trail and a person who approves it, so you don’t delete production in nine seconds.

Data that can’t leave a site stays there. Lena Hall, Senior Director of Developer Relations at Akamai, explained what control means in production: locality. For some use cases, “the data cannot leave certain environments”. Her example was a warehouse robot near products not yet released: its data stays in one geo, in a confined environment. Open-weight models, fine-tuned and deployed close to the data and the user, let you keep control over location, data and latency. Her last advice was containment too: agents can perform dangerous operations, “so make sure you use sandboxing and safe environments.”

The four layers, together

No single layer is enough. Identity tells you who the agent is and for whom it acts, policy says what it may do, observability proves what it did and finds what went wrong silently, and containment limits how far a mistake can go. Each of the seven conversations is on Udienza:

• AI governance at WSO2, with Rania Khalaf
• Agents that actually work, with Nathan Slavik of Arcade.dev
• Securing agents inside the enterprise, with Spencer Reagan of Airia
• Durable execution for agents, with Mark Fussell of Diagrid
• Catching the silent failures of MCP servers, with Kashish Hora of AgentCat
• AURA, an open source SRE agent, with Andre Elizondo of Mezmo
• Agents in production, at the edge, with Lena Hall of Akamai

Related

• AGNTCon North America 2026: Every Takeaway
• AGNTCon North America 2026 Day 1: MCP Tasks and Skills
• AGNTCon North America 2026 Day 2: Small Models, Swap Drills