Blog

Where Agentic Architecture Has To Go

2026-07-062 min read

The security requirements of agentic systems are pointing us toward an architectural outcome nobody is talking about yet.

Traditional services-based architecture has been structured such that a service should be able to verify user entitlements before performing actions on their behalf. Agentic systems break this in multi-user environments due to a property called ‘mutable context’ which is the scratchpad agents use to analyze a request, break it into sub-tasks, and delegate those sub-tasks to other agents. This means we don’t have authorization lineage – a reliable way to propagate the identity of the original requesting user or service.

The current state of the market is largely looking at what permissions these agents should be executing with, without solving for the authorization lineage issue being introduced by agentic architecture. Since agents must carry permissions for every action they could perform on behalf of any user, least privilege collapses under this paradigm. Further, the direction they are pushing the market is unmanageable, considering the simple math of Palo Alto Networks, a 16,000 employee company, reporting enterprises average 109 AI identities for each human identity.

Restoring Authorization Lineage Is The Priority

Granular permissioning on a per-agent basis at scale won’t work. SELinux never caught on because people don't have the interest or bandwidth to be doing the type of fine-grained permissioning required just to restrict these agents at scale, they use service accounts".

If every execution carries the entitlements of the originating identity, you stop caring about which agent is performing an action because the entitlements map back to that originating user or service. In theory, restoring authorization lineage means we can abstract out the scary parts of agentic systems and start treating them as any other distributed system where we’re focused on governing execution using authorization boundaries. However, this is when persistent memory rears its ugly head.

Persistent Memory Mandates Agent Pools

Persistent memory introduces a critical confidentiality issue. Agents responding from memory bypass authorization boundaries, leaking data to unauthorized users.

Authorization lineage restores least privilege, enforcing “no read up”. So now we need to implement a solution to enforce “no write down” – and at this point I expect anyone with a CISSP to see where this is going. The challenge of implementing security classification is that agents still need to be available to handle requests, which brings us to the concept of multiple independent levels of security (MILS) where multiple instances of the same agent, with different security levels, are executing independently of each other, each with their own persistent memory.

Microservices and Ephemerality

Agentic is a distributed system, once we start exploring delegation to specialist agents it starts sounding like a microservices architecture. So let’s talk about enterprise scale with pools of agents servicing MILS, this is not going to be an evenly-loaded system. Engineers at frontier AI labs are already grappling with the compute cost of these systems. Agents being deployed as ephemeral microservices offers the elasticity needed to deliver a performant agentic environment and minimize cost. The security requirements of the systems we’re building are taking us in a direction that consequently optimizes us for operational efficiency.

This is the inevitable outcome.

IntentGraph has coined the platform delivery of this vision as Agent Lifecycle Governance and has multiple patents pending. Contact us to continue the conversation.