API-level controls are now central to agentic AI security

At a glance

What this is: Aryaka argues that agentic AI security has to move from prompt inspection to operation-level controls across embeddings, retrieval, tool calls and model outputs.

Why it matters: This matters because IAM, PAM and AI security teams need to govern when an AI system can read, reason, call tools and re-ingest data, not just what it says.

Context

Modern AI applications are no longer single-turn chat interfaces. They are distributed workflows that move data through model calls, retrieval layers, external tools and storage systems, which creates governance gaps that prompt filters alone cannot close.

The security problem is that each semantic boundary carries a different risk. Embeddings can expose enterprise content, retrieved context can be poisoned, and tool calls can become executable intent, so control has to align to the operation rather than the chatbot surface.

Key questions

Q: How should security teams secure agentic AI systems that can call tools and make independent decisions?

A: Security teams should treat agentic AI as a runtime identity and policy problem, not just a prompt filtering problem. The control set should include least privilege, authenticated tool access, isolation for code execution, detailed logging, and policy checks before actions reach databases, files, or external tools. Without those controls, an agent can turn a helpful workflow into an unauthorized access path.

Q: Why do prompt filters fail as the main control for AI agents?

A: Prompt filters only address the input layer, while most business risk appears after the agent has access to tools and data. Once an agent can make downstream choices, the dangerous action may be fully valid from a prompt perspective and still unacceptable from a governance perspective. Control has to extend to actions, not just text.

Q: How should security teams prevent data poisoning in RAG systems without breaking retrieval quality?

A: Security teams should enforce access control at the retrieval layer, not inside the LLM, and pair that with document filtering, source allowlisting, and response checks. The goal is to stop untrusted content from entering context in the first place, then detect suspicious instructions or outlier embeddings before they influence generation. This reduces the chance that poisoned documents shape answers at scale.

Q: What is the difference between prompt injection and tool poisoning in agentic systems?

A: Prompt injection manipulates the content the model reads, while tool poisoning manipulates the tool itself or its description so the model follows malicious instructions. Both aim to control agent behaviour, but tool poisoning is especially dangerous because the abuse is embedded in a trusted integration path.

Technical breakdown

Why prompt-only security misses agentic workflows

Prompt-only security assumes the dangerous content is visible as plain text at the model boundary. In agentic systems, that assumption fails because the model alternates between user input, retrieved context, reasoning text, structured tool arguments and returned tool data. Each of those is a different trust boundary. A malicious instruction can arrive through a document, a URL, an embedding source or an agent memory update, then only become harmful when it is converted into executable intent. Practical visibility has to follow the data flow, not just the conversation transcript. Read Threat Modelling AI Agents.

Practical implication: Inspect every semantic boundary separately instead of applying one blanket prompt policy to the whole application.

How operation-level policy changes control of OpenAI APIs

The article describes policy decisions at the API operation level, such as blocking embeddings, allowing embeddings with semantic DLP, permitting model output but blocking tool invocation, or allowing only specific tools. That matters because the same application can use the same provider for very different security-sensitive actions. Operation-based policy reduces ambiguity by tying enforcement to request type, path and schema. It is a more precise control model than treating all AI traffic as generic inference traffic. Practical governance depends on knowing which operation is being requested before the model or tool is allowed to proceed. See the AI Infrastructure Workload Identity Guide.

Practical implication: Classify AI traffic by operation and enforce policy before the request reaches the model or external tool.

Why validation profiles must match the risk at each boundary

Validation is not a single check. Inputs, outputs, tool arguments, retrieved references and embedding payloads each require different controls. Prompt injection checks belong on model inputs, schema and intent validation belong on tool inputs, and DLP or grounding checks belong on retrieved content that re-enters the model. URL safety, sensitive-data detection and malware scanning are also boundary-specific controls. This design matters because applying the wrong validator at the wrong point creates blind spots or false positives. The real architectural insight is that control selection must follow the meaning of the data, not just its transport format.

Practical implication: Map each validator to the exact boundary it protects and avoid reusing one control for unrelated risk types.

Threat narrative

Attacker objective: The attacker wants to convert untrusted text or data into unsafe model behaviour, unauthorized tool use or enterprise data exposure.

1. Entry occurs when a user prompt, retrieved document or external URL introduces untrusted content into the AI workflow.
2. Credentialed or structured intent is then formed when the model turns that content into tool arguments, agent memory updates or executable action requests.
3. Escalation follows when the agent is allowed to call tools, query external systems or re-ingest poisoned context without boundary-specific validation.
4. Impact is achieved when the system leaks data, executes unsafe actions or propagates poisoned output into downstream workflows.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.

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

Operation-level inspection is the right control model for agentic AI. The article shows that modern AI systems do not fail at the prompt alone. They fail at the points where prompts become tool calls, retrieved context, embeddings and executable intent, which is why security has to move from text filtering to boundary-aware governance. Practitioners should treat each operation as a distinct control decision.

Agentic AI creates a new trust boundary between reasoning and execution. The model is not just generating language, it is selecting actions and issuing structured inputs to external systems. That makes the delegation layer the real security problem, especially where a task-scoped access model is absent and tools are broadly available. Practitioners should govern tool authority as carefully as human privilege.

Semantic inspection points: is the most useful concept in this article because it captures where security must actually happen. The relevant risk is not merely prompt injection, but the conversion of content into policy-relevant actions at the wrong boundary. That framing is stronger than generic AI content safety because it explains how enterprise controls should attach to the workflow. Practitioners should align control design to the semantic stage, not the model brand.

The article also reinforces that AI security and identity security are converging. Once an agent can call Jira, query databases or fetch URLs, the real question becomes who or what is authorised to do that work. That puts AI agent identity, delegated authority and workload identity into the same governance conversation. Practitioners should include identity in every AI control review.

Security teams should expect AI governance to become more operational, not less. The use of allowlists, schema enforcement, DLP and content validation shows that effective AI control will look like a policy engine across request types. That is a stronger governance pattern than post-hoc review because it limits unsafe action before execution. Practitioners should prepare to govern AI systems by operation, not by application label.

From our research library:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: Threat Modelling AI Agents

What this signals

Semantic inspection points: will become the practical design language for AI security programmes that have moved beyond chatbots. Teams will increasingly need to decide which validation belongs on inputs, outputs, retrieved references and tool arguments, because the control problem changes at each boundary.

The same governance model will also shape identity decisions. As agentic systems inherit more delegated authority, security teams will need to distinguish between model capability and runtime permission, then align that distinction with workload identity for AI systems. Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.

For practitioners

• Implement operation-level policy enforcement Tie policy to specific OpenAI API paths and request types so embeddings, responses, conversations, audio and image operations are governed differently.
• Map validation to semantic boundaries Apply prompt injection checks to model inputs, schema validation to tool arguments, and grounding or DLP controls to retrieved content that re-enters the model.
• Restrict tool invocation by default Allow model output where appropriate, but deny tool execution unless the tool is explicitly approved, scoped and monitored for the task at hand.
• Treat retrieved content as untrusted Scan URLs, documents and reference material for safety, sensitivity and poisoning risk before the model consumes them.
• Instrument AI workflows for auditability Log which operation was requested, what data entered the boundary, which tool was called and what output was re-ingested for later review.

Key takeaways

• Modern AI applications create security risk at multiple semantic boundaries, not just in the prompt itself.
• Operation-level policy and boundary-specific validation are the controls that matter when retrieval, tools and memory all sit inside one workflow.
• Agentic AI governance increasingly overlaps with identity governance because delegated execution is the real control point.

Related NHI Mgmt Group resources: AI Infrastructure Workload Identity Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Threat Modelling AI Agents

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Semantic Inspection: Semantic inspection is the analysis of meaning, intent, and content in AI prompts or outputs rather than only headers, packets, or protocol patterns. It helps detect policy violations, sensitive-data exposure, and manipulation attempts that conventional security tools cannot see. This is central to governing generative AI safely.
• Tool Misuse: Tool misuse occurs when an agent uses an allowed integration in a way that exceeds its intended task, scope, or risk tolerance. The problem is often not access alone but the combination of valid credentials, broad permissions, and unbounded action sequencing.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect identity controls to modern automation and machine access.