We have spent the last few years teaching AI systems how to find information.
That work matters. An AI system cannot produce a trustworthy answer if it cannot identify the right dataset, understand what that dataset means, or account for how current and complete it is. In a federated enterprise, these are difficult problems. Data is distributed across clouds, databases, object stores, and systems that were never designed to share context with one another.
But agentic AI introduces a harder question.
What happens when the system is not only answering a question, but taking an action?
An agent might query a governed data product, create a report, update a catalog, schedule a job, change a policy, or initiate a workflow in another system. At that point, knowing where the data lives is not enough. The agent also needs to know what it is allowed to do with that data, on whose behalf, under which policy, and with what accountability.
The next phase of enterprise AI will be defined by that distinction.
From answering questions to taking action
A traditional analytics system generally waits for a person to initiate an action. A user opens a dashboard, submits a query, or asks an analyst to investigate an issue. The system still needs strong access controls, but the human remains visibly present in the loop.
Agents change the shape of that interaction.
An agent can interpret an objective, choose tools, make a sequence of decisions, and act across multiple systems. It may start with a natural-language request and finish by querying several sources, joining the results, creating a data product, and sending a recommendation to another system.
That creates a larger authorization surface.
The relevant question is no longer simply, can this user access this table? It becomes, can this agent, acting on behalf of this user, use this data for this purpose, take this action, in this environment, at this point in time?
Those are not the same question. Treating them as the same is one of the ways organizations will accidentally give agents more authority than they intended.
An agent is a new kind of principal
Many organizations still model access around two categories: people and applications.
That model is becoming incomplete. Modern data platforms already manage human users, service accounts, machine identities, workloads, and integrations. Agents add another category: a software actor that may have delegated authority, make decisions dynamically, and invoke tools on behalf of someone else.
An agent should not automatically inherit the full permissions of the person who started a conversation. Nor should it be treated as an anonymous application simply because it is software.
A useful authorization model needs to preserve the relationship between:
- The human or system that initiated the request
- The agent that interpreted and executed it
- The tools and services the agent invoked
- The data and resources those tools accessed
- The policy decisions made along the way
This is a chain of identity and delegation. It is more useful than a single username attached to the final query.
A future audit record may need to answer something like:
{ "subject": "user:analyst-42", "actor": "agent:forecasting-agent", "delegation": "delegation:7f3a...", "audience": "trino-cluster-prod-east", "purpose": "quarterly-forecast", "action": "query", "resources": ["sales.orders", "finance.targets"], "constraints": { "export": false, "expires_at": "2026-08-05T18:00:00Z" } }
The point of the example is not the exact schema itself. Rather, the point is that the system needs to preserve the difference between the person who requested something, the agent that acted, and the authority granted for that specific action.
Without that chain, an organization may know that an action happened without being able to answer the more important questions of why it happened, who authorized it, and whether the agent was operating within its intended boundaries.
This is why agentic AI is not only an application-layer problem. It is an identity and access-control problem.
From long-lived credentials to ephemeral token fabrics
With this in mind, the next frontier does not involve giving every agent another long-lived service account.
Long-lived credentials are difficult to scope, difficult to rotate, and difficult to attribute. They also create a dangerous failure mode wherein once an agent or tool obtains one, the credential may be usable well beyond the task for which it was originally issued.
A better pattern is an ephemeral token fabric.
I use that phrase to describe an authorization layer that mints short-lived, audience-bound credentials for specific agent actions. The token is not simply proof that an agent exists. It is a constrained capability. It says that this actor may perform this action, against these resources, for this purpose, until this time, in this environment.
A token fabric would typically combine several ideas:
- Workload identity, so the agent runtime can prove which workload is making the request
- Token exchange, so a user or service identity can be exchanged for a narrower, task-specific token
- Delegation, so the relationship between the initiating principal and the agent is preserved
- Audience binding, so a token issued for one tool or service cannot be replayed against another
- Short expiration, so authority naturally decays instead of persisting indefinitely
- Proof of possession, so stealing a token is not enough to use it from an untrusted runtime
- Revocation and cancellation, so a running workflow can be stopped when risk changes
This is not a replacement for existing standards. Rather, it is an architectural pattern that can bring workload identity, OAuth token exchange, capability-style authorization, and policy evaluation together.
The important shift is from authenticating once at the beginning of a conversation to authorizing continuously as the agent moves through a workflow.
The agent should not receive one broad credential and then operate unchecked. Instead, it should receive the minimum authority required for the next step, and the system should be able to issue a new, narrower capability as the workflow evolves.
Access is not authority
There is an important difference between being able to reach a resource and being authorized to use it.
A network connection can tell an agent how to reach a database. A credential can authenticate the request. A role can grant a set of permissions. None of those things alone explains whether the action is appropriate in context.
A trustworthy agent needs authorization that accounts for more than a static identity. It may need to consider:
- The user or service that delegated the action
- The agent’s purpose and declared task
- The specific data product, table, or column involved
- The sensitivity and classification of the data
- The environment where the workload is running
- The action being requested
- The time window and duration of the authorization
- The policy and regulatory requirements that apply
This is where RBAC and ABAC need to work together.
RBAC remains useful for expressing durable organizational responsibilities. A role can establish that someone is a finance analyst, platform administrator, or data steward. But agentic workflows require more contextual decisions than roles alone can express.
ABAC can incorporate attributes about the subject, resource, action, environment, and purpose. A policy might allow an agent to read aggregated sales data during a forecast workflow while denying access to raw customer records or external export actions.
The most practical model is often hybrid, meaning that roles establish baseline authority, while attributes and runtime context narrow that authority for each action.
An agent that can query a dataset may not be allowed to export it. An agent that can create a report may not be allowed to share it externally. An agent that can read a policy may not be allowed to modify that policy. The difference is authority, not connectivity.
Policy needs a runtime architecture
How do policy and architecture intersect? Policy language alone does not create governance. The platform also needs a clear runtime path for making and enforcing decisions.
A useful model separates several responsibilities:
- A policy administration point manages and versions policy.
- A policy decision point evaluates whether a requested action is allowed.
- Policy information points provide identity, data classification, lineage, environment, and other context.
- Policy enforcement points sit at the boundary of the data source, tool, API, or control-plane operation and enforce the decision.
This separation makes policy portable without pretending that enforcement can happen in one central location.
The decision may be made by a shared service, but enforcement should happen close to the protected resource. A query engine needs to enforce data access. An MCP server needs to enforce tool access. A deployment service needs to enforce infrastructure operations. A policy-management API needs to enforce who can change policy.
The same authorization decision may therefore have multiple enforcement points, all using a common policy model and a common identity chain.
That is how an organization can have one governance posture without creating one giant security perimeter.
The trust boundary is distributed
There’s another aspect to consider as well. The infrastructure underneath enterprise AI is not becoming simpler.
For example, data may remain in an on-premises system because of regulation. Compute may run in a customer-owned cloud account because the workload cannot leave the customer’s network. A model may be hosted by a third party, while an agent runtime operates inside a private environment. Different business units may use different identity providers, policy systems, and deployment models.
The agent still needs to operate across that landscape.
This is where the idea of portability becomes more important. Data portability is valuable, but it is only one layer. Operational portability matters too, meaning that the ability to run managed services close to the data while preserving a consistent operating model.
Agentic portability adds another layer. Identity, policy, and auditability must remain meaningful as the agent crosses deployment boundaries.
A permission model that works in a vendor-hosted environment but disappears when the workload runs in a customer VPC is not portable. An audit trail that records the final query but loses the initiating user and delegated agent context is not sufficient. A policy that protects a table in one environment but is not propagated to the same data product elsewhere creates a false sense of consistency.
The data does not need to move to a single place for governance to be coherent. But the meaning of identity, authority, and accountability needs to remain consistent wherever the work happens.
MCP does not solve governance by itself
Protocols that let agents discover and invoke tools are an important part of the agentic ecosystem. They make it easier to connect models to data, applications, and operational systems.
But exposing a tool does not answer whether the agent should be allowed to use it.
An MCP-style interaction needs to carry more than a bearer token. The authorization context should account for the initiating principal, the agent identity, the requested tool, the target resource, the intended action, and the relevant policy constraints.
The server should validate the token audience, confirm that the delegation is still valid, evaluate policy, and produce an audit event that preserves the chain of responsibility. It should also avoid becoming a confused deputy. Specifically, an agent should not be able to use a broadly privileged server connection to perform actions that the initiating user could not perform directly.
The tool interface is only one part of the trust boundary.
The most durable pattern is likely to be one where agents use common interfaces, but authorization remains grounded in the same identity and policy systems that govern non-agentic access. AI should not create a second, weaker security surface.
The agent may be a new kind of principal, but it should not require an entirely separate definition of trust.
The control plane should unify policy, not centralize data
This leads to a more useful way to think about the control plane.
A control plane does not need to own every workload or store every piece of customer data. Its role is to provide consistent semantics for the things that must remain consistent: identity, policy, lifecycle, observability, and accountability.
That distinction matters.
How do you get the best control plane? Centralizing data can simplify some operations, but it can also conflict with residency, security, cost, and architectural requirements. Centralizing policy semantics is different. It means that the organization can define what a role, entitlement, data classification, or delegated action means without forcing every workload into the same physical environment.
The strongest architecture may therefore combine:
- Data and compute that remain close to the systems that govern them
- A common identity model across deployment environments
- Policy enforcement at the point where data and action meet
- A shared audit model that preserves the full chain of responsibility
- Ephemeral authorization that limits blast radius
- Operational tooling that gives administrators one coherent view
That is not a single centralized system. It is a common operating model across distributed systems.
What trustworthy agentic access should look like
The industry will develop more detailed patterns over time, but several principles are already clear.
Every agent needs an explicit identity
An agent should not be indistinguishable from the user, service, or API key that launched it. The system needs to identify the agent itself and preserve its relationship to the initiating principal.
Delegated authority should be scoped
Agents should receive the minimum authority required for the task. Scope can include the resources, actions, purpose, environment, and duration of the delegation.
Tokens should be ephemeral and audience-bound
Credentials should be short-lived, constrained to the intended tool or service, and unusable outside the workload or channel for which they were issued.
Policy should be evaluated where the action occurs
A central policy definition is useful, but enforcement must happen close to the data and the resource being changed. The local environment is often where the most relevant context exists.
Actions should be attributable
An audit record should make it possible to reconstruct not only what happened, but who initiated the action, which agent performed it, which tools were invoked, what data was accessed, and which policy decisions allowed it.
Authority should be revocable
An organization should be able to stop an agent, invalidate a delegation, rotate a credential, or remove a permission without waiting for an entire workflow to complete.
Safe failure should be the default
When the system cannot establish the necessary identity, context, or policy, the agent should fail closed or reduce the scope of its action. A confident response is not a substitute for a valid authorization decision.
The question enterprises should ask next
The first generation of enterprise AI focused on whether a model could produce a useful answer.
The next generation will ask whether an agent can operate safely in the real world.
That requires more than retrieval quality. It requires a system that understands data context, deployment boundaries, identity, authority, and accountability as one connected problem.
The organizations that move fastest will not necessarily be the ones that give agents the broadest access. They will be the ones that can give agents precise authority and still explain every action afterward.
The future of agentic AI is not just about bringing the model to the data.
It is about bringing the right identity, policy, and accountability with it, one ephemeral capability at a time.
Want to learn more about how Starburst can help enable agentic AI in an enterprise environment? Read the whitepaper.
