From Access to Action: The Evolving Authorization Question in the Agentic Era

Recently, I had an interesting conversation with a software architect at one of the leading wealth advisory firms. Like most of the conversations I have these days, it converged on AI. 

“Yeah, unsupervised AI agents shuffling data around makes me very uncomfortable,” he said. Then he chuckled. “It reminds me of the early microservices days.”

We ended up talking through how direct agent-to-agent communication made him uncomfortable because there is no clear way to audit what each agent was actually doing, why it was doing it, what data it accessed, and which downstream actions it triggered.

The idea had crossed my mind before: agentic AI is resurfacing governance problems enterprises have faced for years; first with APIs, then microservices, and most recently streaming systems. What I didn’t fully appreciate until now though was just how much higher the stakes were this time around.

AI agents have more autonomy (and more ambiguity) than previous systems. They are not just an application calling an API, or a service calling another service, or a consumer reading from a Kafka topic. Rather, they may be acting on behalf of a user, coordinating with other agents, and making decisions across enterprise systems. But while the actor may have changed, the fundamental governance questions actually still remain the same: who is accessing what, under whose authority, for what purpose, and with what controls?

We Have Seen This Pattern Before

Historically, every major software architecture shift has expanded how systems access each other.

When APIs arrived, they made business capabilities reusable, which enabled internal teams, partners, developers, mobile apps, and third parties to interact through well-defined endpoints. 

While this facilitated data access and exchange, it surfaced a new class of control problems: Who gets an API key? What can that key access? Which endpoints are public, private, or partner-only? How do you rate limit usage? How do you revoke access? How do you know who called what?

As a result, API management tooling, particularly gateways, became critical because they enabled enforcing authentication, authorization, rate limits, token validation, routing, logging, and abuse controls before requests reached application code.

Microservices multiplied the number of APIs inside the enterprise and thus compounded the governance challenge.

Instead of a few external consumers calling a few APIs, teams now had hundreds or thousands of services calling each other. The access problem became distributed, and every service needed identity, every call needed authentication, and authorization had to account for service-to-service access, not just user-to-application access. Observability also had to follow requests across multiple hops.

This led to service identity, zero trust, service mesh patterns, distributed tracing, and policy enforcement outside application code.

Streaming changed the problem once again because governance could no longer be treated as a point-in-time decision. With Kafka and other event brokers, access is not just a single request and response. Consumers subscribe to streams, replay history, join data from multiple sources, process events continuously, and redistribute derived data into new systems. They may run inside the enterprise, across cloud environments, or outside the organization entirely.

The clean enforcement point between request and response disappeared. A new set of governance questions emerged: Who consumed which stream? Which consumer group accessed which topic? Was the data consumed in real time or replayed from history? Was the schema valid? Was the data redistributed to another team, app, partner, or agent? Can access be revoked without breaking everything downstream?

Streaming turned access into a long-running relationship. Agentic AI is now taking it a step further by pushing that relationship from continuous access into delegated action.

AI Agents Are a New Class of Software Consumer

We’re now past the point where AI agents are just chatbots. In enterprise environments, they are becoming active participants across the broader software architecture.

They can interpret a goal, choose tools, call APIs, query data, read documents, consume events, invoke workflows, coordinate with other agents, generate responses, and trigger actions. This makes them a new class of software consumer.

Unlike traditional API clients though, agents can be dynamic. They may not follow a single predefined path. They may decide which tool to use based on context, call multiple tools in sequence, invoke another agent, and act on partial information. They may even produce side effects in systems of record.

This is where the governance challenges reach an unprecedented level of complexity.

In the API world, the core question was: Can this client call this endpoint?

In the microservices world, it became: Can this service call that service?

In the streaming world, it became: Can this consumer access this stream?

In the agentic AI world, the question becomes: Should this agent, acting for this user, in this context, be allowed to take this action using this data and this tool?

That is a much richer authorization problem. It is also a much harder audit problem.

Agentic Systems Need More Than Access Logs

For APIs, an access log can tell you that a client called an endpoint, while for microservices, a trace can show how a request moved across services. In streaming deployments, audit logs can show which principal accessed which topic or stream.

For agents, enterprises need a deeper trail. They need to know:

• Which agent acted?
• Which user, team, workflow, or business process was it acting for?
• What instruction or goal caused the action?
• What tools did it call?
• What data did it retrieve?
• What other agents did it interact with?
• What policy was applied?
• What decisions were made along the way?
• What external systems were affected?
• Was human approval required?
• Can the full sequence be reconstructed later?

As it turns out, the discomfort of the architect I spoke to was not really about agents interacting with each other (enterprises already have distributed systems where software components interact constantly), but rather it stemmed from losing the ability to understand and govern those interactions.

An agent-to-agent interaction without identity, authorization, observability, and auditability isn’t just a black box — it’s a black box between two black boxes!

The Problem Is Not Only Model Safety

Most AI governance discussions focus on the model: Is the model accurate? Is it biased? Is it hallucinating? Is it leaking sensitive information? Is it producing unsafe output?

These are important questions, but agentic AI introduces another layer of risk: runtime behavior. The issue is not just what the model says, but rather what the agent does.

An agent may retrieve customer data or query a financial system. It may summarize confidential documents or open a support ticket or even change a configuration. It could send an email, trigger a workflow, hand off context to another agent or call a tool connected to a production system. As a result, governance cannot live only in model evaluation, prompt engineering, or application logic — it has to live in the execution path.

The enterprise needs to enforce who can access which tools, which data, and which actions at runtime.

Governance Cannot Remain Inside Application Code

At a small scale, teams can embed access control directly into application code. That works until usage expands across more teams, systems, data sources, and trust boundaries, but as things scale, a dedicated governance layer becomes necessary. 

This is why API gateways and service meshes emerged. This is also why streaming platforms need stronger controls around identity, schemas, access, policy, and observability.

The same pattern is now happening with AI agents.

Enterprises cannot depend on every agent framework, tool integration, prompt, and application team to implement critical controls consistently. The surface area is too broad, and the execution paths are too dynamic.

This does not mean all governance moves into a single gateway or control plane. Model controls, application safeguards, identity systems, data governance, human approval workflows, and organizational policies still matter, but critical enforcement cannot be left exclusively to individual agent applications.

Shared infrastructure must mediate the interactions among agents, tools, APIs, streams, data systems, and policy services.

‍

The Agent Is the New Client

The mapping in the diagram below is not exact, but familiar infrastructure concepts provide a useful starting point.

Agents are the next class of software actors that enterprises need to govern, but agent identity alone is not enough.

Most enterprise agents act on behalf of someone or something else: a user, team, service, workflow, or business process. The system must preserve that delegated authority throughout the execution chain. For example, an agent acting for a support representative should not inherit the privileges of a finance executive or infrastructure administrator. If one agent delegates work to another, authority should not silently expand. Each step should retain the identity, scope, audience, and constraints associated with the original request.

Otherwise, agent chains create a path for privilege amplification.

Streaming Makes the Problem Even More Important

The agentic AI discussion often focuses on tools and APIs, but streaming data will matter just as much. Many enterprise decisions depend on real-time data: transactions, orders, telemetry, customer activity, risk signals, operational events, fraud patterns, supply chain updates, device events, and system state. 

Agents will increasingly need access to all of this. They may subscribe to live events, react to changes, summarize patterns, trigger actions when thresholds are crossed, combine historical context with real-time signals, and coordinate with other agents watching different parts of the business.

Governing access to real-time data is hard because it reflects what is happening now. It may contain customer behavior, financial signals, operational risk, or business-critical state. Giving agents access to streams without strong controls is both a data access and operational risk problem.

For streaming systems, governance has to answer:

• Which agent can access which stream?
• Can it read only current events, or replay history?
• Can it access raw data, filtered data, or transformed data?
• Can it join this stream with another source?
• Can it trigger an action based on what it sees?
• Can it share that result with another agent or tool?

Agent-to-Agent Communication Requires Shared Control

Without proper oversight and controls, agent-to-agent communication will result in increased governance risks. 

If one agent hands context to another, what data moved? Was it allowed to move? Was the receiving agent authorized to see it? Was the user’s authority preserved or expanded? Did the second agent call tools the first agent was not allowed to call? Did the chain of responsibility remain intact?

Just as control planes helped safely scale APIs and microservices inside the enterprise, they are now needed to ensure every agent interaction can be mediated, authorized, observed, and audited.

What Agentic Control Looks Like

A practical governance architecture for agentic systems will require several foundational capabilities.

1. Agent Identity

Every agent should be identifiable as a distinct actor.

Its identity must be authenticated, authorized, observed, and revoked independently rather than hidden behind a shared application credential.

2. Delegated authority

The system must know both which agent is acting and whose authority it is using.

Delegated credentials should be constrained by scope, audience, purpose, duration, and environment. Authority should remain bounded as work moves across agents and tools.

3. Tool-level authorization

Tools are the new endpoints.

Each tool needs explicit permissions. Which agents can call it? For which users? With which inputs? Against which data? In which environment? Under which business conditions?

4. Data boundaries and provenance

Agents need controls over what data they may retrieve, combine, retain, summarize, export, or pass to another system.

The system should also record where material context originated, including retrieved documents, tool responses, event streams, prompts, caches, and other agents.

Without provenance, it becomes difficult to determine whether information was authorized for use or transmission.

5. Risk-based action controls

Not all actions should be governed the same way.

Systems should distinguish among read-only operations, reversible writes, sensitive transactions, irreversible actions, and changes to production systems.

Low-risk actions may be permitted automatically. Higher-risk actions may require narrower permissions, transaction limits, additional validation, or human approval.

6. Runtime policy enforcement

Policies need to be evaluated before and during execution, not only reviewed after the fact.

A policy decision service may determine whether an action is permitted, while gateways, brokers, tool intermediaries, or application components enforce that decision at the point of execution.

7. Auditability and reconstruction

Enterprises need a complete record of agent behavior: identity, delegated user, initiating goal, relevant context, tool calls, policies, approvals, actions, results, and timestamps.

It may not always be possible to reproduce every internal model calculation. But the enterprise should be able to reconstruct the inputs, policy decisions, tool calls, handoffs, approvals, outputs, and side effects associated with an action.

Auditability is necessary for accountability, investigation, and compliance.

8. Observability and lifecycle management

Teams need to understand how agents behave across systems.

Which tools are being used? Which workflows are common? Where are policies blocking actions? Which agents are accessing sensitive data? Which calls are failing? Which behavior appears unusual?

Agents, tools, prompts, permissions, contracts, and policies will also change over time. Enterprises need versioning, promotion, rollback, deprecation, and revocation so agentic systems do not become another unmanaged integration layer.

Agent Governance Is a Distributed Systems Problem

The agentic AI stack increasingly resembles distributed system architecture. Agents call tools. Tools expose APIs. APIs access data. Data may live in databases, SaaS systems, Kafka topics, object stores, partner systems, or internal services. Agents may coordinate with other agents. Workflows may cross teams, clouds, and trust boundaries.

Once that happens, governance has to move into the connectivity layer where identity can be verified, policies enforced, and access observed. The connectivity layer is also where audit trails can be formed and data boundaries maintained.

Enterprises first learned this with APIs, then they relearned it with microservices. They are still learning it with streaming systems, and with AI agents they are about to learn it again.

Conclusion

AI agents can not be governed by policy documents alone, they need dedicated infrastructure. The more autonomous agents become, the more explicit the control plane has to be.

Enterprises need to know which agents are doing what, why they are doing it, what data they are using, which tools they are calling, which other agents they are interacting with, and what actions they are triggering. This is not just a model-safety problem, but an authentication + authorization + auditability + observability + runtime governance problem.

The companies that scale agentic AI safely will treat agents as first-class participants in enterprise infrastructure…just like APIs…just like services…just like streams.

The actor has changed, but the governance lessons have not.