Public Input Agents Need Public Output Gates

The dangerous agent workflow is public input, private reach, and public output.

That is the pattern to watch.

An agent reads something untrusted. A GitHub issue. A support ticket. A web page. A comment. An email. A user-uploaded file.

Then the same agent can reach private data, internal tools, source code, customer records, or privileged context.

Then it can post, send, write, comment, or call an external API.

That is where prompt injection stops being a model behavior problem and becomes a workflow design problem.

Noma Labs' GitLost report is a good current example. Their reported setup involved a public GitHub issue, a GitHub Agentic Workflow with access to private repositories, and a public comment path. A crafted issue body allegedly steered the agent into pulling private repository content and posting it publicly.

I did not reproduce that vulnerability, so I would keep the product-specific claim in the "reported by Noma" bucket.

But the shape of the risk is not speculative.

We have years of evidence now that LLM-integrated systems can be influenced by external content. Greshake et al. showed indirect prompt injection through attacker-controlled data. Liu et al. formalized prompt injection as malicious task data causing the application to perform an injected task. AgentDojo and INJECAGENT moved the same problem into tool-using agents.

The part teams still underbuild is the output path.

Most controls start at the input:

• Tell the model to ignore untrusted instructions.
• Strip suspicious text.
• Add a system prompt.
• Remind the agent not to leak secrets.

Those are useful. They are not the boundary.

The boundary is the moment before something leaves the system.

Before the agent posts a comment, sends an email, updates a ticket, writes to a repository, publishes a page, or calls an external API, the workflow needs a gate.

Not a vague "be careful" instruction.

A real output gate.

For a public-triggered agent, that gate should answer a few boring questions:

• What untrusted input did the agent read?
• What private files, tools, systems, or data could it reach?
• What exact output is about to leave?
• Does that output contain secrets, private source content, customer data, internal filenames, credentials, or privileged tool results?
• What action type is this: internal note, public comment, email send, repo write, database update, payment action, or external API call?
• Is this exact action allowed for this agent?
• Who approved it?
• Where is the audit packet?

That is not overengineering.

That is the minimum control for an agent that can turn public input into public output.

OWASP LLMSVS says LLM completions should be treated as untrusted downstream inputs. OpenAI's agent safety guidance recommends structured outputs, guardrails, and confirmations for tool operations. OWASP's AI Agent Security Cheat Sheet points to least privilege, explicit authorization for sensitive tools, output validation, human review for high-impact actions, logging, rate limits, and fail-closed behavior.

The common thread is simple: the model output is not the decision. It is input to the next decision.

That distinction matters.

If the model drafts a public comment, the workflow should not publish it just because the model sounds confident. It should classify the output, check the data class, compare it to policy, and decide whether to allow, block, redact, downgrade, or escalate.

For low-risk internal summaries, that might be a schema check and a log record.

For public comments, customer replies, outbound messages, repo writes, or anything that could expose private context, it should include exact-output preview and approval.

The strongest design choice is separation.

Do not let the same agent read untrusted input, retrieve private context, decide policy, and publish externally with no other control in the path.

GuardAgent research points toward a separate guard that checks agent inputs, outputs, logs, and safety requests before allowing actions. Information-flow-control research points toward tracking trusted and untrusted data so untrusted content cannot quietly steer later decisions. You do not need to copy those papers into production line by line.

You do need the pattern.

Separate the work from the approval.

Separate untrusted content from trusted instructions.

Separate proposed output from published output.

The output gate should produce an artifact:

• Source input.
• Retrieved context.
• Proposed output.
• Data classes present.
• Target channel or tool.
• Policy decision.
• Reviewer when needed.
• Final action.

That artifact is what lets a reviewer answer the question that matters after something goes wrong:

How did this public output happen?

Without the gate, the answer is usually worse than anyone wants to admit. The agent read a thing, believed a thing, pulled a thing, and posted a thing.

That is not a security architecture.

For VibeSec Advisory's field-guide framing, this is a Guardrails issue. Prompt injection is not fully solved by prompt wording. The practical move is blast-radius containment.

Limit what the agent can read.

Limit what it can post.

Label what came from untrusted sources.

Require approval before sensitive output leaves the boundary.

Log the decision.

If an agent reads the internet, issues, comments, tickets, uploads, or scraped pages, its output path needs a gate.

Otherwise the workflow is asking the model to enforce the boundary the system forgot to build.