Most enterprise AI security programs are aimed at the wrong layer. The conversation centers on prompt injection, model behavior, and output filtering. Those are real concerns. But the actual attack surface is the infrastructure surrounding the agent — the credentials it holds, the data it can read, and the knowledge it acts on.
That distinction matters enormously for every organization deploying agents right now.
Why the context layer is the biggest unaddressed attack surface
Every AI agent operates on context. In practice, that context includes Slack messages, CRM records, financial data, internal documents, email threads, and customer information — whatever you've fed the agent to make it useful.
When you deploy an agent without governing its context layer, you're creating a single, queryable interface to your most sensitive business data. An attacker who can manipulate what the agent reads — or who can read what the agent has access to — doesn't need to crack your database. They just ask.
Security researchers studying agentic systems have converged on the same point: the identity infrastructure that gives an agent permission to act is the actual attack surface, not the model itself. Agents authenticate with credentials, assume IAM roles, and access data stores through entitlements. Compromise the agent's identity or context access, and you've compromised everything downstream.
Cisco's definition of AI agent security calls for a multi-layered defense strategy that governs agent behavior while securing the underlying infrastructure — not just the model layer. That framing is right, but most enterprise deployments haven't operationalized it.
Agent deployment is accelerating faster than governance. The gap between how quickly organizations are shipping agents and how carefully they're governing the context those agents operate on is where the real exposure lives. Speed without structure is how breaches happen.
The OWASP MCP Top 10 and what it signals
The emergence of a dedicated OWASP Top 10 list for MCP (Model Context Protocol) is a signal that the industry is catching up to the threat surface. MCP is the protocol that connects AI agents to external tools and data sources — it's the pipe through which context flows.
The risks in that list aren't theoretical. When an MCP server exposes company data to an agent, that server becomes a high-value target. If the server lacks proper authentication, scoping, or permission controls, an attacker who can reach it can query everything it knows.
Prompt injection through MCP tools is a documented risk category: malicious content embedded in a retrieved document can contain instructions that redirect the agent's behavior. Because the agent treats retrieved context as trusted input, an attacker who can influence what the agent retrieves can effectively control what it does next — without ever touching the model. Security researchers including those contributing to the OWASP MCP project have published proof-of-concept demonstrations of this class of attack; real-world exploitation in production enterprise environments has not yet been widely disclosed, but the mechanism is well understood and the incentive to exploit it is growing.
This is why the architecture of your context layer matters as much as the security of your model.
The three context security failures enterprises are making right now
1. Indexing everything without permission scoping
The fastest way to deploy an AI agent is to point it at all your data and let it answer questions. The fastest way to create a breach is the same thing. When a single agent can read HR records, financial projections, and customer contracts with equal access, a single compromised session exposes all of it.
A concrete example: an engineering team deploys an internal agent connected to Notion, Google Drive, and Slack. No permission scoping is applied. A junior contractor queries the agent and receives verbatim content from a board-level M&A document that happened to be indexed. No credentials were stolen. No model was jailbroken. The context layer just had no walls.
Proper context security requires granular permission scoping: some knowledge is private (one person), some is team-level, some is company-wide. The agent should only retrieve what the querying user is entitled to see.
2. No source attribution on retrieved context
When an agent answers a question, can you tell exactly which document or record it drew from? Without source citation, you can't audit what the agent accessed, you can't detect anomalous retrieval patterns, and you can't investigate a breach after the fact.
Consider what this means in practice: if an agent is queried 200 times in a day and one of those queries retrieves a sensitive compensation file, you need to know which query triggered that retrieval, what was returned, and who asked. Without source attribution baked into every retrieval, that forensic trail doesn't exist.
Source attribution isn't just a UX nicety — it's a forensic requirement.
3. Stale context that creates false confidence
Context that was accurate three months ago may now be wrong. An agent operating on outdated data doesn't just give bad answers — it gives confidently wrong answers that can drive bad decisions. Stale context also means your permission model may no longer reflect reality: employees who left, projects that closed, data that was supposed to be deleted.
A practical example: a sales agent is trained on a customer context snapshot from Q1. By Q3, the customer has churned and their account has been flagged as sensitive. The agent, operating on stale context, continues surfacing that account's data in responses — including to team members who no longer have a business reason to access it.
What a secure context layer actually looks like
The architecture that addresses these failures has four properties:
Selective indexing. The organization chooses exactly what gets ingested — not a blanket crawl of everything. This limits blast radius by design.
Permission inheritance. Context access mirrors the permissions that already exist in the source systems. A user who can't read a Salesforce opportunity in Salesforce shouldn't be able to get that information through an AI agent either.
Source citation on every retrieval. Every answer the agent gives should be traceable to the specific document, message, or record it drew from. This makes auditing possible and anomaly detection tractable.
Continuous freshness. The context layer stays current as the underlying data changes — no manual re-indexing, no stale snapshots creating drift between what the agent knows and what's actually true.
This is the model Gyld is built on. Rather than requiring you to build and maintain a custom RAG pipeline — and the security controls around it — Gyld acts as the business context layer for AI — ingesting data from the apps you already use (Slack, Gmail, Outlook, Notion, HubSpot, Salesforce, Google Drive, QuickBooks, and more), applying permission scoping at the knowledge level, and exposing that context as MCP servers that any AI agent can plug into. Every retrieval is source-cited. You control exactly what gets indexed.
If you've been evaluating RAG versus other approaches to grounding AI in company data, the security properties of the context layer should be a primary evaluation criterion — not an afterthought.
How to assess your current exposure
If you're deploying agents today, run through this checklist:
- What data can your agent access? List every source explicitly. If you can't enumerate them, that's the first problem — and it means your blast radius in a breach scenario is unknown. Start by pulling the list of integrations or data connectors your agent uses and mapping each one to a data sensitivity tier.
- Who controls what the agent can retrieve? Is access scoped per user, per team, or is it flat? Flat access means any session — including a compromised one — can reach everything. Test this by querying your agent as a low-privilege user and checking whether it returns data that user shouldn't see in the source system.
- Can you produce an audit log of what the agent retrieved in a given session? If not, you can't investigate a breach. Run a test query, then ask your security team to reconstruct exactly what was retrieved and from where. If they can't do it in under ten minutes, your forensic posture is inadequate.
- How old is the context your agent is operating on? When was it last updated? Check whether your indexing is event-driven (updates when source data changes) or scheduled (batch snapshots). Scheduled indexing creates predictable staleness windows that can be exploited.
- What happens if your MCP server or context endpoint is reached by an unauthorized client? Is there authentication? Scoping? Send a request to your MCP endpoint without valid credentials and observe what happens. If it returns data or errors that reveal schema information, your authentication layer needs work.
These aren't advanced security questions. They're the baseline. The fact that most enterprise agent deployments can't answer all five is the gap that the context layer attack surface illustrates — and the gap that a well-architected context layer closes.
Key takeaways
- The real enterprise AI agent security attack surface is the context layer — what the agent knows and can retrieve — not the model itself.
- The three most common failures are flat permission scoping, missing source attribution, and stale context — most enterprise deployments have at least two of these gaps.
- A secure context layer requires selective indexing, permission inheritance from source systems, source citation on every retrieval, and continuous freshness.
If your agents are operating on unscoped, unsourced, or unaudited context, you're not running a security program — you're hoping. Start building your company brain with proper context controls at Gyld.
Frequently asked questions
What is AI agent security in an enterprise context?
AI agent security for enterprises is the practice of governing what autonomous AI systems can access, authenticate as, and act on — covering identity infrastructure, data entitlements, and context sources. The model itself is one layer; the context it operates on, the credentials it holds, and the permissions it inherits are equally important and often less governed.
What is the OWASP MCP Top 10?
The OWASP MCP Top 10 is a list of the most critical security risks associated with Model Context Protocol servers — the infrastructure that connects AI agents to external tools and data. It covers risks including prompt injection through retrieved content, insufficient authentication on MCP endpoints, and overly broad tool permissions.
How does prompt injection work in an agentic system?
In an agentic system, prompt injection occurs when malicious content embedded in a retrieved document, database record, or tool output contains instructions that redirect the agent's behavior. Because the agent treats retrieved context as trusted input, an attacker who can influence what the agent retrieves can effectively control what it does next — without ever touching the model.
What's the difference between securing the model and securing the context layer?
Securing the model focuses on the AI system's behavior: preventing harmful outputs, resisting jailbreaks, filtering responses. Securing the context layer focuses on what the model is allowed to know and retrieve: permission scoping, source attribution, freshness, and audit logging. Both matter, but most enterprise security programs have invested heavily in the former and almost nothing in the latter.
Why is source attribution important for AI agent security?
Source attribution creates the forensic trail that makes breach investigation possible. Without knowing exactly which document or record an agent retrieved in a given session, you can't detect anomalous access patterns, you can't scope a breach after the fact, and you can't demonstrate compliance with data access policies. It's the difference between an auditable system and one you're operating on trust.