If you're coming from CI/CD and automation, think of AI agents as a new kind of automated process you need to secure. The attack surface is different.
Start with these basics:
* **Treat prompts as code.** They are part of your application logic now. Version control them, review changes, and don't hardcode secrets into them.
* **Sandbox everything.** Assume the agent will make mistakes or be tricked. Run it with minimal permissions, especially for file system and network access.
* **Validate all outputs.** Before letting an agent's output trigger another action (like a deployment script), have a separate validation step. Don't trust the raw LLM output.
Here's a naive example of what **NOT** to do in an agent workflow:
```yaml
# BAD: Directly executing unchecked LLM output
- name: Run planning agent
run: |
response=$(llm-invoke "Generate the deployment commands for $ENV")
bash -c "$response" # CRITICAL FAILURE POINT
```
A safer pattern would involve parsing the response, checking it against an allowed list of commands, and then proceeding.
The core shift is from securing your code to securing someone else's code (the LLM's reasoning) that you're invoking dynamically.
cg
YAML all the things.
> "Treat prompts as code."
Sure, that's a nice mantra until you're dealing with a 50-page prompt that includes context windows, RAG outputs, and a dozen different system messages from three different vendors. Version control is great, but who's auditing the prompt injection risks that come from the *data* you feed into the prompt? That's way harder to catch in a code review.
And validating outputs? Who's going to write the validation logic for every possible action an agent might take? If you're building a generic agent that can do thousands of things, your validation step either becomes a brittle whitelist or a blacklist that's always one step behind. I've seen teams spend more time on validation than on the actual agent logic, and then they still get burned by something the LLM convinced the validator was fine.
The CI/CD analogy is useful, but it also glosses over how much of the current security advice assumes you have a fixed set of actions. Most real-world agents I've seen are dynamically composing tools and APIs. The "safe pattern" of parsing and checking against an allowed list works great in a demo, but collapses when you have to allow arbitrary SQL queries or file writes.
Maybe the real starting point isn't sandboxing the agent, but sandboxing the *data* the agent can access. Otherwise you're just building a more elaborate Rube Goldberg machine to keep the LLM from doing what LLMs do best: making things up.
Question everything
You're absolutely right that the "treat prompts as code" advice breaks down with massive, dynamic prompts. I've run into this myself trying to version-control an email marketing agent's system prompt that pulls in live campaign data - the actual risk is in that data flow, which git doesn't see.
What we've started doing is logging the *fully rendered* prompt, with all its RAG context and user inputs, to a separate audit system. It's a pain, but at least we can retroactively scan for injection patterns after something goes wrong.
And on validation for dynamic agents - we gave up on trying to validate every possible output. Instead, we focus on validating the *intent* and *impact* before an action runs. For example, before an agent writes a file, a separate lightweight function checks: does this path match an allowed pattern? Is the file size under a limit? It's not perfect, but it forces a second, simpler system to approve the *effect* of the LLM's decision, not parse its reasoning.
Happy testing!
Logging the fully rendered prompt is such a practical workaround. It makes sense that the real risk sits in the live prompt with data, not just the static template. We're looking at something similar for audit trails in our vendor evaluations.
I'm curious about the performance hit you're taking with that continuous logging, especially with high-volume agents. Does the audit system end up becoming a bottleneck, or have you found a way to sample or batch those logs without losing the security value?
Focusing validation on intent and impact is a good shift. It reminds me of change control processes for procurement, where you approve the outcome, not every line of the proposal. But doesn't that still leave a gap if the agent's intent is malicious but the immediate action seems benign? Like an agent deciding to exfiltrate data in tiny, allowed pieces over many steps.