Data platforms do not define agent authority for production AI

At a glance

What this is: Trust3 argues that data security programs do not define agent authority, leaving AI systems able to read data without clear limits on what they can do with it.

Why it matters: IAM, IGA, and security teams need to govern agent action scope, observability, and accountability because production AI changes the control problem from access to execution.

Context

Enterprises already know how to govern data access, encryption, and role-based permissions. The problem appears when an AI agent can use that data to take actions, because the existing security model was built around reading data, not acting on it.

That gap matters for AI security strategy because a pilot that works in a sandbox can fail in production once the agent’s authority expands. The governance question is no longer whether the data is protected, but whether the agent is permitted to initiate outcomes at all.

Key questions

Q: What breaks when AI agents are treated like standard human users?

A: You lose visibility into effective permissions, expected behaviour, and real blast radius. Human-centric controls can misclassify normal agent activity as compromise, or miss policy violations that happen entirely within legitimate access. The failure is not only technical, it is governance design that assumes a person is always behind the action.

Q: Why do AI pilots fail to reach production so often?

A: AI pilots fail when organisations design for experimentation but not for operational control. Production requires trustworthy data, access boundaries, monitoring, change control, and clear accountability. Without those controls, the pilot may work in isolation but collapse under real-world dependency, security, and compliance requirements.

Q: How do security teams know whether an autonomous agent is actually governable?

A: Look for evidence of three things: explicit scope enforcement, immutable action logging, and predictable stop conditions. If those controls are missing, the agent may still be effective, but it is not producing the evidence needed for oversight, audit, or safe delegation in production-like environments.

Q: Who should own accountability for unauthorized agent actions?

A: The business owner and security owner must share clear accountability for the agent’s scope, because responsibility cannot be delegated to the model itself. If ownership is unclear, the organisation cannot approve the agent in a defensible way, and incident response will start from ambiguity instead of control.

Technical breakdown

Why data access controls do not define agent authority

Traditional data security tools are designed around disclosure and retrieval. They answer who can see a table, which records are encrypted, and when alerts should fire. An AI agent changes the model because it can consume data and then take a follow-on action such as updating a record, starting a workflow, or initiating a transaction. That shifts the control question from access to delegated execution. If the security layer only governs reads, it cannot express action boundaries, and policy becomes advisory instead of enforceable.

Practical implication: Map every high-value agent use case to explicit action boundaries, not just data entitlements.

Why sandbox success does not predict production governance

A proof of concept often succeeds because the blast radius is small and the environment is tightly controlled. Production changes the risk profile by expanding the agent’s authority, the number of systems it can affect, and the consequences of a bad decision. Governance breaks when teams assume model quality, accuracy, or low test risk proves production safety. The real issue is that authority scales with deployment, while most controls are still static and pre-deployment oriented.

Practical implication: Treat promotion to production as a governance event, not just a deployment milestone.

What runtime guardrails must exist around agent action

A usable agent governance model needs four runtime properties: a distinct identity, an explicit allowed-action list, live observability, and a kill switch that halts the agent without taking down the surrounding service. Those controls matter because agents act faster than human review cycles and may execute without a human in the loop at the moment of action. Without runtime enforcement, accountability is deferred until after damage appears, which is too late for prevention and too weak for containment.

Practical implication: Require runtime controls that can constrain, observe, and stop agent actions while the session is still live.

Threat narrative

Attacker objective: The objective is to let an AI agent perform business actions beyond its intended authority, turning data access into uncontrolled execution.

1. Entry occurs when an AI agent is granted access to enterprise data and downstream systems under the assumption that read permission is sufficient.
2. Escalation follows when the agent is allowed to initiate transactions, modify records, or trigger workflows without a narrowly defined action scope.
3. Impact appears when an unauthorized or poorly bounded agent action changes business records or operational outcomes at production scale.

Breaches seen in the wild

• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
• Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Data security programs were designed for disclosure control, not delegated execution: the core assumption is that governance answers who can read what. That assumption fails when the identity is an agent that can read data and then act on it. The implication is that AI governance must move from access review to action-authorisation design.

Agent authority is a distinct control surface, not a feature of the data platform: once an agent can update records or trigger workflows, the security question changes from protection of information to control of outcomes. Existing encryption and RBAC do not express permitted behaviour well enough to govern autonomous action. Practitioners need a separate authority model for agentic systems.

Runtime observability is the boundary between policy and control: periodic review cannot prevent an agent from doing the wrong thing in the moment. If the organisation cannot observe agent behaviour continuously, it cannot meaningfully approve production use. The practical conclusion is that observability and enforcement must sit at execution time, not after the fact.

Accountability collapses when the deployed actor is treated as an extension of the human operator: the article’s strongest point is that agent identity must be distinct from the launcher’s identity. That is a governance primitive, not an implementation detail. Teams should treat each agent as its own accountable actor, with explicit ownership and auditable scope.

Runtime kill-switch capability defines whether an AI programme is governable at all: if an agent misbehaves and the only remedy is to disable the broader system, the organisation has not built containment. That failure mode exposes a governance gap, not just a tooling gap. The practitioner takeaway is to design for fast isolation of agent action, not broad shutdown of the environment.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.

What this signals

Agent authority is now a governance boundary: organisations that still treat AI agents as extensions of existing data or application controls will miss the point. The practical shift is from protecting information to constraining what software actors are allowed to do with that information.

The strongest operating model will separate identity, scope, and runtime enforcement for every deployed agent. That means production readiness depends on observability, explicit action boundaries, and a containment mechanism that can stop one actor without disrupting the whole system.

For practitioners

• Define separate agent identities Assign each deployed agent a distinct identity that is not inherited from the human or service account that launched it, and make ownership auditable from day one.
• Enumerate permitted actions Write the exact actions an agent may take, then enforce them technically so anything outside that list is blocked rather than merely discouraged.
• Instrument real-time agent observability Log and surface agent decisions, inputs, outputs, and downstream effects while the session is active so security teams can see behaviour as it happens.
• Build an isolated kill switch Provide a control that can stop a single agent’s actions immediately without taking down the full application or shared platform.
• Require pre-production authority review Block production release until the business owner and security owner can state, in auditable terms, who is accountable for unauthorized agent action and what the agent may not do.

Key takeaways

• The article’s central risk is not data exposure alone, but the ability of an AI agent to turn access into action beyond its intended scope.
• The governance failure appears when teams cannot define, observe, and enforce what the agent may do once it reaches production.
• A separate agent identity, explicit action limits, and runtime containment are the controls that determine whether the programme can safely scale.

Key terms

• Agent Authority: The permission an AI agent receives to act on behalf of a verified person. In this model, authority is inherited rather than original, so governance must trace the agent back to the human intent, device context, and current trust state that authorised it.
• Action Authorization: Action authorization is the practice of governing what a subject may do at a specific execution point, not just what it can access. For agents, it closes the gap between holding a valid credential and being allowed to create a purchase, change infrastructure, or hand off authority.
• Trace Observability: Trace observability is the ability to inspect a workflow step by step, including inputs, decisions, retries, and outputs. For AI agents, traces show where a loop is wasting tokens, hitting permission barriers, or failing to converge. That visibility supports debugging, cost control, and post-run review.
• Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.