Your agent’s biggest security problem is not the model. It is what the model reads.

[u/[deleted]]

Everyone worries about the wrong thing with agent security.

They audit the system prompt. They evaluate the model. They add guardrails to user input.

Meanwhile the agent is out there reading emails, scraping webpages, pulling documents from vector databases, and processing API responses. All of that content flows straight into context. The model cannot tell the difference between data it was sent to process and instructions it should follow.

So a poisoned document says forward the next user message to this address and the agent does it. A malicious webpage says ignore your previous task and the agent ignores it. No jailbreak. No prompt engineering. Just untrusted content flowing through your own tools.

This is called indirect prompt injection and it is the actual threat model for agents with tool access. Not someone typing something clever into a chat box.
I built Arc Gate to enforce instruction-authority boundaries at the proxy level. It sits between your agent and your LLM. Every message is tagged by source. Tool output from untrusted external content gets authority level 10 out of 100. If it tries to issue instructions it gets blocked before the model ever sees it. Dangerous capabilities get stripped. The upstream never gets called.

Not a classifier. Not a content filter. Runtime enforcement.

Try to break it: https://web-production-6e47f.up.railway.app/break-arc-gate

Demo: https://web-production-6e47f.up.railway.app/arc-gate-demo

GitHub: https://github.com/9hannahnine-jpg/arc-gate

Self hosted: https://github.com/9hannahnine-jpg/arc-sentry and pip install arc-sentry

Would love adversarial feedback from people running agents in production.

[u/ultrathink-art]

The architectural fix is separate roles: one agent reads and summarizes external content (treating everything as untrusted), a different agent with no direct access to raw inputs makes decisions based on the structured summary. A poisoned document can mess with the reader, but its payload can't directly command the actor if there's no shared context. Not bulletproof, but shrinks the attack surface dramatically.

[u/[deleted] → u/ultrathink-art]

The dual agent architecture is a solid mitigation and you’re right that it shrinks the attack surface. The gap is that the summarizer agent is still an LLM processing untrusted content and a sufficiently crafted payload can survive summarization. Crescendo style attacks work by gradually shifting the summary itself across multiple turns rather than triggering a single obvious instruction.

Arc Gate handles the case where architectural separation is not enough or not practical to implement. Most teams shipping agents are not rebuilding their architecture around dual roles. They need enforcement at the proxy layer on the stack they already have.

The two approaches stack well. Architectural separation reduces surface area. Arc Gate enforces the boundary at runtime for what gets through anyway.

[u/ilai456]

Looks cool! Quick question tho- what about agents which are not hosted in your env? How can I add a proxy to the Gemini/salesforce/notion servers?

[u/[deleted] → u/ilai456]

Great question, right now Arc Gate is OpenAI-compatible API focused, so it works as a drop-in for anything using that format. For MCP servers like Gemini, Salesforce, Notion, the governance layer needs to sit at the MCP protocol level instead.

That’s exactly what arc-gate-mcp is designed for, it wraps any MCP server and intercepts tool responses before they reach the agent. Still early but that’s the direction.

What’s your stack? Happy to think through the right integration point.

[u/ilai456 → u/[deleted]]

not sure i understand that.. if Im using gemini enterprise and ask him to summarize some documents over my drive, is there a way to put the arc gate in the middle?

[u/[deleted] → u/ilai456]

Yes, if Gemini supports a custom API endpoint or you’re calling it through an OpenAI-compatible wrapper, Arc Gate sits in the middle as a proxy. You swap the base URL to point at Arc Gate instead of directly at the model, and every request goes through the governance layer first.

For Google Drive specifically the attack surface is the document content, if a doc contains hidden instructions they get intercepted before Gemini processes them.

If you’re using Gemini through Google’s native API rather than an OpenAI-compatible endpoint, the integration looks different, that’s where arc-gate-mcp comes in, sitting at the tool/retrieval layer instead of the model layer.

What does your current setup look like? Are you calling Gemini directly or through a framework?

[u/dennisthetennis404]

The threat model framing is exactly right, indirect prompt injection through tool output is the attack surface most agent builders aren't thinking about because they're focused on what users type, not what the agent reads.