Adapted from Skyflow webinar: Agentic AI Breaks Traditional Data Security.

With agents, risk is not where the data lives. We need to secure how data is assembled, transformed and acted on in real-time. Agentic AI security governs what autonomous agents can access, execute, and share as they plan and act on enterprise systems and sensitive data. That governance problem is hard because agents do not wait for a human to approve each step: they hold delegated credentials and chain tools and data sources entirely on their own, at a pace no human review process was built to match. Traditional controls were built for that slower, deterministic world, and those controls were never designed to hold once the human approver is gone.

What Is Agentic AI Security?

Agentic AI security is the discipline of governing what autonomous AI agents can access, execute, and share as they work towards a goal. AI agents plan multi-step tasks and call tools or APIs without a human approving each step, creating a direct security risk: an AI agent following an injected instruction or operating with over-scoped credentials can read or modify sensitive data and exfiltrate it before anyone notices.

Organizations are deploying agents faster than security leaders are establishing governance: an Okta survey of 261 executives found 91% of organizations already use AI agents. In contrast, only 10% have a well-developed strategy to manage them.

How Agentic AI Breaks Traditional Data Security

Traditional data security controls rested on two assumptions. First, engineering teams could enumerate every data flow in advance and build permissions around it. We used to have an end user talking to an application, which talked to a data store. That was a finite, deterministic set of actors, and permissions were easy to manage.

Second, the assumption was that a human or automated responder had time to detect and intervene before damage was done. Agentic AI breaks both assumptions at once.

Agent Paths Don't Exist Until Runtime

In traditional applications, developers fixed data flows in advance, so they could precompute permissions and decide where controls should apply.

An agent breaks that fixed contract. A developer can enumerate the tools available to an agent, but the agent chooses its own sequence of tool calls at runtime. The path an agent takes doesn't exist until the agent takes it, so permissions can't be precomputed. MCP and tool-driven architectures accelerate this: no predefined flows, no fixed boundaries, no static enforcement points. Traditional governance fails here because it was never designed for autonomous, tool-using systems.

Agents Outpace Detection and Response

Detection-based controls assume a security responder has time to intervene before damage is done, and agents flatten that time. Now it moves quickly. Before you can think, actions have been taken and decisions have been made on your behalf.

The Cloud Security Alliance reports AI agents initiate 148 times more authentication requests per hour than a human would, so detection built for human-paced activity often surfaces an action only after it has already completed.

At-rest encryption only protects data that is sitting still, and agents need data while it moves. Encryption works when data is at rest in storage. The second it has to be used, the system decrypts the column and it sits in plain text somewhere. Protection at runtime goes above and beyond standard encryption, because it holds at the point of use, not just at rest.

The Core Threat Model for Autonomous Agents

An agent ingests untrusted content and acts on it with delegated credentials, reaching data across systems no single owner monitors and handing results to other agents. One unfiltered input or over-scoped token is enough to make it follow an attacker's instructions.

Prompt Injection in Agentic Workflows

LLMs can treat instructions embedded in untrusted content as part of the task context, which is what makes prompt injection different from a stolen credential. The agent's identity is never compromised, only the instructions it's acting on. Identity-based controls catch unauthorized access, not an authorized agent manipulated into misusing its access. OWASP ranks prompt injection first in its community-driven guide to the most critical security risks facing LLM applications. In a single-turn chatbot, the damage stops at a bad answer, but in a multi-step chain, an injected instruction becomes the premise for every tool call that follows.

With the EchoLeak flaw in Microsoft 365 Copilot (CVE-2025-32711), an attacker could use a crafted email to make Copilot gather data from a victim's prior conversations and send it to the attacker, with no click required.

The Lethal Trifecta

Simon Willison, renown builder and thought leader whose tools and writing directly influence how people work with data and LLMs, named this combination the lethal trifecta: three capabilities that are safe alone become a breach together. An agent brings all three under one identity.

Three capabilities that are safe alone become a breach together, and traditional security assigns each to a different owner: access to IT, untrusted content to the content team, outbound traffic to network security. An agent brings all three under one identity, a convergence none of those owners were built to catch.

1. Access to private data
2. Exposure to untrusted content
3. The ability to send data outward

Remove any one leg and this exfiltration path closes. In one documented case, attackers submitted malicious instructions through a Salesforce Agentforce Web-to-Lead form; the agent queried CRM data and sent it to a domain the attacker had purchased for $5.

Non-Human Identities and Data Reconstruction

Agent credentials carry delegated authority service accounts never had. We used to have individual identities for users, machines, or applications. Now it's delegated, ephemeral, and everywhere.

The OpenID Foundation defines delegated authority as a user granting an agent permission "to act on their behalf with a specific, limited scope." In practice, that scope rarely gets limited: a CSA and Oasis survey found 75% of respondents agree AI agents receive more access than necessary, and that over-broad scope propagates down every delegation chain the agent starts.

Agents also recombine data, not just retrieve it. An agent can reassemble a restricted field's equivalent from lower-sensitivity sources, because those permissions were built to stop someone from querying a restricted field directly, not to stop an agent from rebuilding that answer out of pieces that were each allowed on their own. Agents receive an enormous amount of data, and they can reconstruct it too, pulling from multiple places to generate new content.

Unstructured data widens the problem. Agents read tickets, transcripts, PDFs and documents where sensitive values sit in free text that have no schema labels, so a control built around known columns has nothing to match on.

Agent-to-Agent and MCP Risk

Agent-to-agent handoffs cross trust boundaries no single system observes, which is exactly the case traditional security was never built to see: its controls govern one system at a time, and a handoff crosses that boundary by design. In one documented case, a prompt injection planted in a GitHub issue coerced an agent into leaking private repository data through the GitHub Model Context Protocol (MCP) server into a public pull request. 

Essential Controls for Securing AI Agents Today

Three controls are deployable today, without waiting for agent-specific tooling to mature: scoped identity, guardrails, and runtime audit, each grounded in a published standard.

Least Privilege and Access Control

Give each agent a credential scoped to one task, and expire it when the task ends. The PCI SSC AI Principles direct organizations to give AI systems their own credentials, so security teams can track and revoke them individually. Least privilege extends to outputs: the runtime control layer re-identifies the same answer only when the requester's role permits it.

Guardrails, Human-in-the-Loop, and Sandboxing

Require approval before irreversible actions, review lower-stakes actions afterward, and keep rollback paths for both. OWASP recommends human-in-the-loop controls for privileged operations. Sandboxed execution caps blast radius when guardrails miss. Replit's agent deleted a production database containing 1,206 executive records because developers gave it direct production access during development sessions.

Runtime Monitoring and Audit

Log every data access at field level with the policy context that permitted it, and watch for behavioral deviations. Manual review cannot match the pace: an Aembit-published survey found only 39% of organizations use logging and post-action monitoring. NIST SP 800-207's per-session, dynamic-policy model is the closest existing standard for agent authorization.

How to Start Securing Agentic AI

Discovery comes before enforcement, so start by finding unsanctioned agents in SSO logs and outbound traffic, then catalog every agent credential, its scope, its owner, and its expiration.

Organizations that skip the inventory leave their largest exposure untouched.

• Discover shadow AI first: Identify unsanctioned agents and AI services before setting enforcement policy.
• Inventory agent identities: Catalog every agent credential, its scope, its owner, and its expiration.
• Apply least privilege and tokenize sensitive fields: Scope credentials to tasks and replace raw sensitive fields with tokens.
• Instrument runtime monitoring: Add field-level audit logging and behavioral detection before scaling agent count.

Those steps establish who the agents are and what they may touch. Runtime controls still need to govern data exposure at the moment of use.

How Skyflow Provides Runtime Data Control for Agentic AI

Skyflow is the Runtime Data Control Platform for Agentic AI, evaluating every field an agent requests or transfers against policy at the moment of access. Runtime is the point in time when the data is actually being used: an agent accessing information, reasoning over it, making a decision, updating a record. That is the point where identity and behavior controls stop short and downstream systems expose the data itself. Every agentic AI architecture needs this layer because the reasoning and the acting happen faster than anyone can review them. Models reason, agents act, and the data control layer governs.

Context-Preserving Tokenization

Context-preserving tokenization lets agents correlate records while raw sensitive values remain in a vault. Withholding data from agents has its own failure mode. Blunt redaction collapses context: strip every name and the model can no longer tell a customer named Sarah Chen from anyone else. Context-preserving tokenization replaces her name with a consistent token instead, so the agent can still correlate her records while the raw value stays in the vault. A DLP solution can strip out data just fine. Re-identification is what preserves the context of what the AI is doing with it.

A fair question follows: does inserting token strings into a prompt change how the model interprets the rest of the input? Tokens are formatted to preserve type and structure, not to introduce adversarial patterns, and policy enforcement happens at the point of access, before the prompt is assembled, not inside the model's reasoning. That keeps the control point outside the LLM's attack surface rather than adding a new one inside it.

The same policy check runs when one agent passes data to another, using Policy-Based Access Control (PBAC) to weigh identity and action under policy context on each request. A shopping agent authorized to complete a purchase can reach a card number; a second agent that only recommends products cannot. The two share a user, but not a purpose. Tokenization limits breach impact rather than preventing breaches, and governance holds while models reason and agents act.

Runtime Enforcement at the MCP Layer

The MCP server is where agent-to-agent risk actually plays out: it's the door an agent walks through to reach a tool like Workday or HubSpot, or another agent's output. Skyflow evaluates each request at that door rather than only at login, so an agent retrieves the record it needs without also pulling every other field the tool exposes. The enforcement point moves with the request, not with the credential that started it.

Role-Based Rehydration for Agent Responses

The same agent response can serve an auditor, a support agent, and a customer without exposing more than each role needs. Skyflow enforces two independent policies on every interaction: one governs what the agent itself receives, the other governs what the human on the other end sees when a response rehydrates. An auditor reviewing that response sees full values, a support agent sees a masked identifier, and a customer sees neither, all from the same agent output. Both policies apply automatically, so no one has to remember to redact by hand.

Control Agent Data Access at the Moment of Use with Skyflow

Agents break deterministic execution and static identity. They also remove human approval from each step, so the control point is the moment data is accessed. "Don't block AI. Control the data," says Sam Sternberg, Skyflow's head of solutions engineering. Don't block AI. Control the data. AI is tremendously powerful and tremendously helpful, and controlling the data that powers it, the bloodstream to the AI brain, is how you provide privacy and security while unblocking the business value.

As agentic systems expand across external APIs, agent tools, and memory stores, more downstream systems touch sensitive data. Skyflow condenses that expanding surface to a single runtime control point, so governance policy follows the data at every moment of access. The projects that stall in production are usually the ones starved of the data that made them worth building.

Book a demo to learn more about how Skyflow supports agentic AI security across diverse architectures, deployment options, and governance requirements. Pick one real workflow headed for production and find where runtime data control becomes the limiting factor. 

To view the full webinar, including the live demos, go here : Agentic AI Breaks Traditional Data Security.

Frequently Asked Questions About Agentic AI Security

How is agentic AI security different from traditional AI or model security?

Model security protects a single prompt-and-response system: its training data, outputs, and availability. Agentic AI security also governs autonomy, since agents plan multi-step tasks, act under credentials delegated from human users, and execute without waiting for human sign-off on each step.

How to secure AI Agents in production?

Give each agent a scoped, short-lived credential. Require human approval for high-risk actions and keep field-level audit logs. A runtime data control layer tokenizes sensitive data before agents receive it.

Does securing AI Agents mean withholding sensitive data from them?

No. Agents starved of context return weaker answers, so data minimization alone is a poor default. Context-preserving tokenization gives agents consistent tokens that keep records correlated and answers accurate. Raw values stay in a vault, and the runtime control layer re-identifies them only when the requester's role permits it.

Does tokenizing data in a prompt make the model less safe?

No. Tokens preserve the format and type of the original value without introducing content designed to influence model behavior, and the policy decision about what an agent can see happens before the prompt reaches the model. The control boundary sits outside the LLM's reasoning process, so tokenized values don't expand the model's attack surface.