Agent Identity, Reliable Execution, and Intent are only half-way solved – n8n Blog
-->
Github ★ 162k
Sign in<br>Get Started
Agent Identity, Reliable Execution, and Intent are only half-way solved
Andrew Green
July 10, 2026 ∙ 5 minutes read
After spending the past couple of months looking at hundreds of tech docs from n8n, Google, Gumloop, and the rest, I tallied up 75 capabilities you’d expect an agent development tool to offer.<br>But there are so many more things you can, need, or should do to agents that weren’t easy or fair to be included in the report, so I’m sharing some of these here.<br>Agent Identity<br>Agents have clearly slipped between the cracks of human and non-human identities, which is problematic because there is no way to keep track of agents, their actions, and their owners. If Agent X decides to go on a data deletion spree, identity would be the thing that can help you identify where it lives and who created the monster.<br>But nobody solved identity yet, and if they claimed to do so, it’s by retrofitting existing techniques to agents, which doesn’t really work (note that Auth is in a better place than Identity, but auth is just a subset of identity).<br>Let’s assume you run agents in n8n. There’s no way to formally define the identity of an agent such that you give it a name badge, some policies, and monitor its activities within the wider environment it works in. You can integrate it with IdPs that support agents, but still need to engineer your way through it.<br>This resource details how it onboards an n8n agent to Microsoft’s Entra Agent ID. While it's behind a paywall, it says you need:<br>A running n8n instance on Azure Container Apps, behind HTTPS ingress, with persistent Postgres and file storage.<br>A Microsoft Entra Agent Identity Blueprint, an Agent Identity service principal, and an Agent User account<br>n8n workflows to execute a Microsoft Graph call, an Auth Manager that brokers tokens, and an on-behalf-of webhook that talks to the Microsoft Graph MCP Server for Enterprise.<br>A working MCP.User.Read.All delegated call from inside the agent.<br>The best option for running this natively as of today is using Google Gemini Enterprise Agent Platform, which is clearly the hyperscaler portfolio advantage. Agent Identity provides a strongly attested, cryptographic identity for each agent that is based on the SPIFFE standard. With Agent Identity, agents can securely authenticate to MCP servers, cloud resources, endpoints, and other agents, acting either on its own behalf or on behalf of an end user. Agent Identity uses the agent's own credential and Agent Identity auth manager. Auth manager can create and manage auth providers, which are the specific configurations used to acquire, manage, and secure API keys, OAuth client IDs, OAuth client secrets, and delegated end-user OAuth tokens.<br>But even Google’s approach (which is one of the most advanced ones at the moment) you can find some critiques, like their usage of SPIFFE. “While SPIFFE can technically provide agent identities, current Kubernetes implementations treat all replicas as identical—a fundamental mismatch with agents’ non-deterministic, context-dependent behavior that creates compliance and attribution gaps”.<br>Agent Reliable Execution<br>LLMs generate the code, agents execute it. And just as a server hiccups and you need to turn it off and on again, agents can hiccup too. All enterprises have been feeling this pain, but I see little to no systematic (or dare I say deterministic) approach to ensure agents execute reliably. There is a selection of tools that are tackling this problem, but adoption is slow.<br>The simplest thing that can execute agent code can be the Python interpreter. You should expect an agent development tool to do more than straight Python, which would be:<br>Prevent confused deputy: where sandboxes (e.g. MicroVMs/Wasm) can run untrusted AI code safely, or provide scoped network access,<br>Durability: detect failures, retry steps, maintain state, check point, validate outcomes<br>Concurrency: resource allocation and handling noisy neighbors as services scale<br>We’ve briefly covered code execution and sandboxes in the report, so let’s look at the other two:<br>Agent execution durability - Agents may hit a rate limit from the LLM provider, have a request time out, or a self-hosted agent can run out of memory.<br>Execution durability can help recover from this sort of incidents by:<br>Checking agent tasks get executed and completed steps are stored<br>If agents are interrupted they start again from the same point<br>They get executed once, not zero or multiple times<br>Agent actions have time awareness such that they wait for other jobs to complete, schedules and such<br>Can go back and try again if output is not validated<br>Concurrency - Agents and the underlying hosting environment compete for memory, CPU, and network calls. When agents share the same infrastructure (i.e. they don’t have isolation), one resource-intensive session degrades every other session. Effective...