Securing AI Agents: Implementing the OWASP Top 10 for Agentic Applications

Traditional web applications have clear request-response boundaries. You validate input, sanitize output, and apply authorization at well-defined checkpoints. But AI agents fundamentally change this model. They make autonomous decisions: which tools to call, what parameters to use, how to interpret results. The LLM is both the brain and the attack surface.

Agents process user input AND tool results as context. A malicious payload in a tool result is just as dangerous as one in a user message. The standard OWASP Top 10 for web apps doesn't cover agent-specific risks like goal hijacking, tool misuse, or memory poisoning. That's why the OWASP Agentic Top 10 exists.

The Biotrackr Chat Agent

To demonstrate these controls in practice, I built Biotrackr - a personal health data tracker with a Claude-powered chat agent. It's a .NET 10 Minimal API running as an Azure Container App, using Microsoft Agent Framework with Claude Sonnet 4.6 via the Anthropic provider.

The agent has 12 function tools that call existing health data APIs through Azure API Management, persists chat history in Cosmos DB, and streams responses to a Blazor UI via the AG-UI protocol. Every step in that pipeline is a potential attack surface.

ASI01 — Agent Goal Hijack

What is it? An attacker manipulates the agent's objectives, task selection, or decision pathways through prompt-based manipulation, deceptive tool outputs, or poisoned external data.

Why it matters for Biotrackr: The chat agent processes user messages and API responses as context for the LLM. A compromised data source could carry a prompt injection payload that redirects the agent's behavior.

What I implemented:

• Strict input validation on all tool parameters (dates validated as DateOnly, page sizes capped at 50)
• Immutable system prompts loaded from Azure App Configuration at startup
• Structured JSON-only tool responses with no free-text fields
• Comprehensive logging of every tool call for audit

👉 Read the full ASI01 post — Preventing Agent Goal Hijack in .NET AI Agents

ASI02 — Tool Misuse and Exploitation

What is it? An attacker exploits tools accessible to the agent. Excessive permissions, lack of rate limiting, or unvalidated parameters allow the agent to perform actions beyond its intended scope.

Why it matters for Biotrackr: The agent has 12 tools calling external APIs. Without constraints, a hijacked agent could exfiltrate data through large result sets or abuse tool calls at high frequency.

What I implemented:

• All tools are read-only (HTTP GET only)
• Date range queries are capped at 365 days
• Page sizes are hard-capped at 50
• Every tool call is logged with OpenTelemetry tracing

The agent simply cannot mutate data.

👉 Read the full ASI02 post — Preventing Tool Misuse in AI Agents

ASI03 — Identity and Privilege Abuse

What is it? An agent operates with excessive privileges or uses a shared identity, allowing it to access resources beyond its intended scope.

Why it matters for Biotrackr: The chat agent calls downstream APIs and accesses Cosmos DB. If it shared the app's identity with broad permissions, a compromised agent could access anything the app can.

What I implemented:

• Microsoft Entra Agent ID gives the agent its own first-class identity with federated credentials
• RBAC is scoped to the minimum required; read-only access to specific APIs and data stores

👉 Read the full ASI03 post — Preventing Identity and Privilege Abuse in AI Agents

ASI04 — Agentic Supply Chain Vulnerabilities

What is it? Vulnerabilities in the agent's dependencies; frameworks, plugins, model providers, or tools that can be exploited to compromise the agent.

Why it matters for Biotrackr: The agent depends on preview-stage NuGet packages from Microsoft Agent Framework and the Anthropic provider. Preview packages can have breaking changes, undiscovered vulnerabilities, or unstable APIs.

What I implemented:

• Pinned NuGet package versions
• Lock files committed to source control
• Dependabot configured for automated dependency updates
• Clear governance process for upgrading preview packages

👉 Read the full ASI04 post — Preventing Agentic Supply Chain Vulnerabilities

ASI05 — Unexpected Code Execution

What is it? The agent executes code that wasn't intended by its designers. Either through code generation tools, dynamic evaluation, or injection into executable contexts.

Why it matters for Biotrackr: Mostly it doesn't. The agent has no code execution tools, no eval(), and no dynamic compilation. This is a deliberate architectural decision that eliminates an entire class of vulnerabilities.

What I implemented:

• The absence of code execution tools IS the control
• Tools only perform HTTP GET requests and return structured data

👉 Read the full ASI05 post — Preventing Unexpected Code Execution in AI Agents

ASI06 — Memory and Context Poisoning

What is it? An attacker corrupts the agent's memory or conversation context to influence future behavior. In multi-turn conversations, earlier messages become "trusted" context that shapes how the agent interprets later inputs.

Why it matters for Biotrackr: Chat history is persisted in Cosmos DB and loaded as context for subsequent interactions. A poisoned conversation turn could influence the agent's behavior across an entire session.

What I implemented:

• Cosmos DB TTL on conversation documents to limit the blast radius of poisoned context
• Bounded context windows so the agent only loads recent history
• Structured message format that separates user messages from system context

👉 Read the full ASI06 post — Preventing Memory and Context Poisoning in AI Agents

ASI07 — Insecure Inter-Agent Communication

What is it? When multiple agents communicate, messages between them can be intercepted, spoofed, or manipulated if communication channels lack authentication, encryption, or message integrity.

Why it matters for Biotrackr: It doesn't. Biotrackr uses a single agent with no inter-agent orchestration. This is worth calling out explicitly because choosing a single-agent architecture eliminates an entire vulnerability class.

👉 Read the full ASI07 post — Preventing Insecure Inter-Agent Communication in AI Agents

ASI08 — Cascading Failures

What is it? A failure in one component (the LLM provider, a downstream API, or a tool) propagates through the agent system, causing widespread outages or degraded behavior.

Why it matters for Biotrackr: The agent depends on Claude's API (via Anthropic) and multiple downstream health data APIs through APIM. If Claude goes down or an API times out, the agent could hang, retry endlessly, or return garbage.

What I implemented:

• AddStandardResilienceHandler() on all HTTP clients for circuit breaking, retry with exponential backoff, and timeout policies
• Graceful degradation in tool responses
• Token budgets prevent runaway LLM calls

👉 Read the full ASI08 post — Preventing Cascading Failures in AI Agents

ASI09 — Human-Agent Trust Exploitation

What is it? Users over-trust the agent's output, treating it as authoritative when it shouldn't be. This is especially dangerous in health, legal, and financial domains where misplaced trust can lead to real harm.

Why it matters for Biotrackr: This is a health data agent. If a user asks "should I be worried about my heart rate?" and the agent gives a confident answer, that's genuinely dangerous.

What I implemented:

• The system prompt explicitly states the agent is not a medical professional
• The UI visually differentiates agent responses from factual data
• Health disclaimers are baked into the agent's behavior

👉 Read the full ASI09 post — Preventing Human-Agent Trust Exploitation in .NET AI Agents

ASI10 — Rogue Agents

What is it? The agent itself becomes the threat. Whether through compromised training data, manipulated system prompts, or lack of runtime constraints, the agent operates outside its intended boundaries.

Why it matters for Biotrackr: Even though the risk is low for a constrained side project, defense in depth means we plan for the worst.

What I implemented:

• All tool calls are logged and persisted for audit
• The system prompt is version-controlled in Azure App Configuration with RBAC
• The agent has no self-modification capabilities
• The architecture supports a kill switch through configuration changes

👉 Read the full ASI10 post — Preventing Rogue AI Agents

Cross-Cutting Themes

A few patterns show up across nearly every control:

• Structured JSON responses — tools return minimal, structured data with no free-text fields that could carry injection payloads
• Input validation at every boundary — tool parameters, API responses, user messages are all treated as untrusted
• Principle of least privilege — the agent identity has read-only access, tools can only query data, and RBAC is scoped to the minimum required
• Observability — OpenTelemetry tracing and conversation persistence create a full audit trail of every tool call and agent response
• Defense in depth — no single control is relied upon in isolation; multiple layers work together

Wrapping Up

The OWASP Agentic Top 10 gives us a structured framework for thinking about agent security, and this series shows how to put it into practice. Start with Part 1 — Preventing Agent Goal Hijack, or jump to whichever vulnerability is most relevant to your architecture.

If you're building agents, I'd strongly encourage you to assess them against the OWASP Agentic Top 10. The framework provides a comprehensive way to think about agent-specific risks that traditional security models miss.

If you have any questions about the content here, please feel free to reach out to me on Bluesky or comment below.

Until next time, Happy coding! 🤓🖥️