Notifications
Clear all
Topic starter
15/08/2026 6:13 pm
TL;DR: Cloud data platforms now expose a wider identity problem than authentication alone can solve, as Britive argues in its October 2025 analysis of Snowflake, Cloudflare, Replit, and token-based access abuse. Once a token, key, or service account can still act after issuance, privilege becomes the real control boundary and runtime governance matters more than login success.
NHIMG editorial — based on content published by Britive: Securing Cloud Data Platforms in the Age of AI and Token-Based Breaches
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.
Questions worth separating out
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.
Q: Why do long-lived tokens increase risk in cloud data platforms?
A: Because they extend the time between issuance and misuse.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Britive's analysis of runtime access control for cloud data and AI agents →
Runtime authorisation for AI agents and data access: what changes?
Explore further
15/08/2026 6:20 pm
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.
A few things that frame the scale:
- 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.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime authorisation for data platforms and AI agents
