AgentGuard

Inspiration

Modern AI agents are becoming powerful because they can read arbitrary context and call tools. That same capability creates a new security problem: a malicious web page, support ticket, document, MCP response, or tool result can smuggle instructions that the agent treats as trusted. AgentGuard was inspired by the need for a simple security boundary that developers can place before untrusted content reaches model context or triggers side effects.

What it does

AgentGuard is a framework-neutral, fail-closed inbound prompt-injection firewall for AI agents. It scans prompts, retrieved documents, web content, MCP output, tool results, and proposed tool calls before they influence an agent. Each scan combines deterministic heuristics, a GPT-5.6 semantic judge through the configured provider, an optional independent DeBERTa probe, and versioned policy evaluation. The result includes an allow/block verdict, risk score, findings, sanitized content, detector provenance, degraded-state metadata, and trace IDs that developers can audit.

How we built it

I built AgentGuard as a Next.js and TypeScript application with stable REST contracts, a dependency-free Python SDK, JavaScript package sources, adapter examples for agent frameworks, and optional AWS CDK infrastructure for batch scanning and an activation-probe service. The runtime path separates trust boundaries: content before model ingestion uses /api/v1/scan, proposed tool calls use /api/v1/check-action as TOOL_CALL, post-tool or retrieval output returns through scan, and large documents are scanned in overlapping chunks with only a final verdict after all chunks complete. Provider keys stay on the server or in encrypted workspace settings.

Challenges we ran into

The hardest part was avoiding accidental permissive behavior. A detector outage, malformed provider response, unsupported tool reasoning trace, or partial streaming result should never silently become an allow decision. Also had to keep the project usable without forcing authentication for the public demo while preserving tenant isolation when PLATFORM_AUTH_REQUIRED=true. Another challenge was documenting external blockers honestly: live GPT-5.6 judging, optional DeBERTa probing, benchmark results, and registry publication all depend on real credentials, deployed services, or package ownership.

Accomplishments that we're proud of

• Implemented a concrete security path with deterministic, semantic, and optional probe evidence feeding versioned policy evaluation.
• Added a first-class TOOL_CALL boundary so proposed actions are reviewed before side effects instead of being confused with post-tool output.
• Preserved fail-closed semantics and exposed provenance, degraded-state, policy, findings, and trace IDs to make decisions auditable.
• Shipped SDK and integration paths so developers can protect custom agents, Python apps, REST clients, and framework adapters with the same boundary.
• Added documentation that separates verified runtime evidence from external credential or deployment blockers.

What we learned

Prompt-injection defense is less about one perfect classifier and more about placing the right boundaries in the agent lifecycle. Scanning must happen before context ingestion, before tool execution, and after untrusted retrieval or tool output. Also learned that security tooling needs explainable failure modes: developers need to know whether a decision came from all configured detectors or from a degraded fail-closed path.

What's next for AgentGuard

Next steps are to run the complete benchmark against the live deployment with real provider credentials, expand adapter coverage, publish packages once the package scopes are available, improve the policy console, and add richer workspace analytics for blocked attacks, false positives, degraded scans, and latency. The longer-term goal is to make AgentGuard a drop-in inbound security layer for any agent stack that consumes untrusted context or uses tools.

What makes it different

• Inbound rather than output moderation: it protects model context before untrusted content can steer an agent.
• Evidence, not a boolean: every verdict includes detector scores, findings, policy provenance, and sanitized text.
• Fail-closed by design: unavailable or malformed mandatory signals cannot silently allow a request.
• Provider-flexible: GPT-5.6 can run through OpenAI or OpenRouter, with encrypted workspace keys and explicit fallback policy.
• SDK-first integration: pip install ./sdk/python, instantiate AgentGuard, and call scan before context insertion.

How GPT-5.6 was used

GPT-5.6 is both part of the product and part of how it was built. At runtime it serves as the semantic security judge, classifying intent, instruction overrides, context theft, secret extraction, and tool smuggling into strict structured evidence. During development, GPT-5.6 Sol was the primary coding agent used to implement and harden the MVP across the Next.js app, Python SDK, tests, provider routing, and AWS infrastructure.

How Codex was used

Codex independently re-checked the trust-boundary architecture and implemented TOOL_CALL as a distinct pre-execution boundary. It hardened /api/v1/check-action, preserved the fail-closed unsupported-reasoning risk floor, added policy/provenance/degraded metadata and trace propagation, added route regression tests, and improved Python SDK test discovery. The work was reviewed through PR #11 and deployed after CI passed

Built With

• amazon-web-services
• deberta
• deployment
• dynamodb
• ecs
• fargate
• long-lived
• next.js-16
• oidc
• probe
• prompt-injection
• react-19
• s3
• secrets-manager
• sqs/lambda
• typescript
• vercel
• vitest-gpt-5.6-via-openai-or-openrouter-python-3.10+-dependency-free-sdk-aws-cdk
• zod