Runtime authorisation for data platforms and AI agents

At a glance

What this is: This analysis argues that cloud data platforms, tokens, and AI agents create a runtime authorisation gap that authentication alone does not close.

Why it matters: IAM, PAM, and NHI teams need to govern what identities can do after login or token issuance, because excessive standing access turns data platforms and AI workflows into high-impact blast-radius zones.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.

👉 Read Britive's analysis of runtime access control for cloud data and AI agents

Context

Cloud data platforms centralise sensitive data, but that centralisation also concentrates identity risk. The problem is not just who can authenticate, but what a human, service account, pipeline, or AI agent can do once access has already been granted. In that model, the primary control point shifts from login to runtime authorisation and session governance.

The article uses recent incidents to show how long-lived tokens, overbroad roles, and static keys can turn one exposed credential into broad data exposure. That is a familiar non-human identity pattern, but the addition of AI agents makes the impact less predictable because runtime actions can be destructive even when the initial access path was legitimate.

Key questions

Q: How should security teams govern API access for AI agents and service accounts?

A: Security teams should treat API access as a governed identity path, not a transport detail. That means assigning ownership to each machine consumer, limiting scopes to specific tasks, enforcing token binding where possible, and maintaining audit logs that tie every call to an identity and policy decision.

Q: Why do long-lived tokens increase risk in cloud data platforms?

A: Because they extend the time between issuance and misuse. If a token remains valid across jobs, tools, and users, one exposure can reach many systems before anyone notices. The longer the credential persists, the larger the blast radius and the harder it is to prove which actions were legitimate.

Q: What do security teams get wrong about OAuth2 in agentic workflows?

A: Teams often assume OAuth2 makes the whole path safe once the client authenticates. In practice, the server and downstream backends must also accept and constrain the same authority, or the integration becomes inconsistent. The mistake is treating delegated authentication as a complete control instead of one layer in a larger trust chain.

Q: Who is accountable when an AI agent accesses the wrong data?

A: Accountability sits with the team that defined the agent’s scope, the owner of the delegated user context, and the operators who allowed access to persist beyond the task. For customer workflows, audit logs should show both the agent and the user identity so responsibility can be traced clearly.

Technical breakdown

Why authentication stops being enough in cloud data platforms

Authentication proves identity, but it does not govern the action boundary after tokens, roles, or service accounts are issued. In cloud warehouses, lakes, and analytics stacks, OAuth and OIDC can establish trust, yet the real risk appears later when the same credential remains valid long enough to query, export, or modify data. That is why runtime authorisation, not just login control, becomes the decisive layer for data systems. The problem intensifies when credentials are reusable across jobs, scripts, and downstream integrations.

Practical implication: map every data platform credential to its runtime permissions, expiry, and revocation path, not just its authentication method.

How JIT and ephemeral credentials change the NHI control model

Just-in-time access and ephemeral credentials reduce the period in which a credential can be abused, which shrinks blast radius when a key, token, or service account is exposed. The architectural shift is important: access becomes task-scoped, time-bounded, and revocable, rather than persistent and assumed safe until expiry. For NHI governance, this means least privilege must be enforced at session level and at resource level, such as schema, table, API, or bucket. It also makes audit trails more useful because access events become finite and attributable.

Practical implication: replace standing roles with task-scoped access windows and automatic revocation across every sensitive data system.

Why policy-aware runtime controls matter for AI agents

AI agents can execute actions through tools, connectors, and protocols such as MCP, which means the security question is no longer only whether the agent is authenticated. The deeper issue is whether the agent should be allowed to act, at that moment, under the current context, and for that specific operation. Runtime controls can compare location, device posture, time, behaviour, and requested action before allowing execution. That matters because an agent that can act autonomously may not be malicious, but it can still produce destructive outcomes if its identity is over-scoped.

Practical implication: treat AI agent permissions as live policy decisions, with approval gates for destructive actions and behavioural monitoring during active sessions.

Threat narrative

Attacker objective: The objective is to turn one compromised identity artifact into broad data access, operational disruption, or destructive changes across cloud platforms and AI workflows.

1. Entry occurs when a contractor credential, static key, or long-lived token is exposed and still accepted by the cloud data platform.
2. Escalation follows when that credential carries broad access to datasets, internal tools, or service accounts, allowing the attacker to move from authentication to data action.
3. Impact emerges as sensitive records, internal systems, or production databases are exposed, modified, or deleted before the access is revoked.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime authorisation is now the primary control plane for cloud data security. Authentication, SSO, and token issuance still matter, but they no longer decide the outcome once access has been granted. The decisive question is whether the identity can keep acting, on what scope, and for how long. Teams that still treat login as the end of the control problem are already behind the threat model.

Standing privilege creates identity blast radius in data platforms. A single key or token that persists across jobs, schemas, and systems turns every data pipeline into a lateral movement path. This is the same governance failure that NHI programmes have seen in cloud workloads for years, only now it extends into analytics and AI operations. The practical conclusion is that blast radius must be bounded at the resource and session level, not assumed safe by role assignment.

Ephemeral credential trust debt: long-lived access accumulates security debt the moment it is issued. The article’s examples show that a reused token or static key can remain valid long after its business purpose has ended. That creates a trust debt between the time access is granted and the time it is actually needed. Practitioners should treat every persistent credential as deferred breach exposure, because the exposure window is part of the control failure.

AI agents make runtime governance a cross-domain identity issue. This is not only an NHI problem and not only an AI problem. Once agents can call tools, query data, or trigger actions, the same governance model must span human approvals, machine identities, and autonomous execution paths. That convergence is where identity architecture either becomes coherent or collapses into disconnected controls.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• From our research: Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• From our research: 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.

What this signals

Ephemeral credential trust debt: teams that keep issuing long-lived keys to data platforms are accumulating exposure faster than their governance processes can clear it. The control gap is no longer just visibility, but the time window in which a credential remains usable after business need has ended.

Practitioners should expect AI and data workflows to converge on the same access model: short-lived permissions, policy checks at execution time, and revocation tied to session completion. That shift aligns with runtime governance patterns described in the Ultimate Guide to NHIs , Static vs Dynamic Secrets, and it is becoming a baseline expectation for security review.

The organisation that can explain who or what touched data, under what context, and for how long will outpace the one that only knows who authenticated. That is where NHI governance, IAM, and AI operational controls now converge, and where auditability becomes a board-level issue.

For practitioners

• Inventory every identity that can touch data systems Map human users, service accounts, API keys, pipelines, and AI agents to the exact datasets, schemas, buckets, and APIs they can reach. Include downstream tool chains and approval paths so you can see where static access still persists.
• Replace standing access with task-scoped JIT windows Grant access only for the duration of a specific job or change window, then auto-revoke it immediately after completion. Apply the same pattern to database roles, storage access, and administrative actions.
• Eliminate static keys from data workflows Remove AWS keys, shared tokens, and embedded secrets from scripts and automation paths, then move to ephemeral credentials bound to user, workload, or agent context. This reduces the chance that one leak becomes persistent access.
• Apply policy checks before destructive actions Use context-aware controls for deletes, exports, privilege changes, and bulk queries. Require approval or step-up verification when an AI agent or privileged user requests an action outside normal behavioural patterns.
• Correlate identity events with session behaviour Track unusual region, time-of-day, device posture, and query volume during active sessions, then tie those signals to automated denial or escalation workflows. That gives security teams a runtime view instead of a post-event audit only.

Key takeaways

• Cloud data security now depends on runtime authorisation, because authentication alone does not control what tokens, keys, or agents can do after issuance.
• Compromised or overbroad non-human identities create outsized blast radius, with one credential able to expose data platforms, internal systems, or production workloads.
• Practitioners should move to JIT access, ephemeral credentials, and policy-aware execution controls before data pipelines and AI agents outpace existing governance.

Key terms

• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Ephemeral Credentials: Ephemeral credentials are short-lived access artefacts issued for a limited task or session. They reduce the window for abuse, but they only improve security when paired with strong scope limits, telemetry, and automatic revocation at task completion.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.

What's in the full article

Britive's full analysis covers the operational detail this post intentionally leaves for the source:

• Specific JIT access workflows for Snowflake, Cloudera, Databricks, SAP, and cloud storage platforms.
• Runtime policy examples for geo, VPN, device posture, and time-of-day checks.
• AI agent guardrail scenarios using MCP Gateway for destructive actions such as deletes.
• Operational workflow integration with ServiceNow, Jira, PagerDuty, Slack, and Teams.

👉 The full Britive post covers JIT access workflows, runtime policy logic, and AI agent guardrails in more implementation detail.

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 building or maturing an IAM programme, it is worth exploring.