Two things happened this week that should make every developer building with AI agents pay attention.
OpenAI launched Codex Security — dedicated security tooling for agentic code. And NIST's comment period on their AI Agent Security guidelines closes March 9, 2026. Two days from now.
The message is clear: the industry has realized AI agents aren't just fancy autocomplete anymore. They read your emails, execute shell commands, push code, and interact with production systems. The attack surface is enormous, and most teams are shipping agents with roughly the same security posture as a chmod 777.
The Gap Is Real
Here's what a typical AI agent setup looks like today:
- Full filesystem access
- Unscoped API keys in environment variables
- No audit trail beyond chat logs
- Prompt injection? "We'll handle that later"
- Secret scanning? "The model wouldn't leak secrets... right?"
If this sounds like your stack, you're not alone. Most agent frameworks prioritize capability over containment. That's fine for demos. It's not fine for production.
OWASP Top 10 for Agentic AI
The OWASP Top 10 for Agentic AI (2026) gives us the first serious taxonomy of what can go wrong. The highlights:
- Prompt Injection — Still #1. Direct and indirect. An agent that reads untrusted content (emails, web pages, user input) can be hijacked.
- Excessive Agency — Agents with more permissions than they need. The principle of least privilege applies here exactly like it does everywhere else.
- Insecure Output Handling — Agent output flowing into downstream systems without validation.
- Supply Chain Vulnerabilities — Plugins, tools, and MCP servers you didn't audit.
- Sensitive Information Disclosure — Agents leaking secrets, PII, or internal data through their outputs.
The rest of the list covers training data poisoning, denial of service, and model theft — important, but the top five are where most agent deployments are bleeding today.
Practical Best Practices
Enough theory. Here's what you can actually implement.
1. Treat Untrusted Input as Hostile
Every email, web page, and user message your agent processes is an attack vector. Build a processing pipeline that:
- Strips or neutralizes injection patterns before they hit the model
- Separates data context from instruction context
- Validates structured outputs against schemas
This isn't paranoia. Researchers have demonstrated prompt injection via invisible Unicode characters, calendar invites, and even image alt text.
2. Implement Permission Tiers
Not every agent action should require the same trust level:
| Tier | Actions | Control |
|---|---|---|
| Read | File reads, web searches, calculations | Auto-approve |
| Write | File edits, API calls, messages | Confirm or allowlist |
| Destructive | Deletions, deployments, financial ops | Human-in-the-loop |
The key insight: define your tiers based on reversibility. Can you undo it? Auto-approve. Can't undo it? Gate it.
3. Scan Outbound Content
This one gets overlooked constantly. Your agent has access to .env files, SSH keys, API tokens, and database credentials. Every outbound message — every chat reply, every email, every API call — should pass through a secret scanner.
Pattern matching for API keys, tokens, and credentials isn't glamorous, but it's the difference between "oops" and "breach."
4. Build Audit Trails
Log every tool call. Every. Single. One.
[2026-03-07T09:15:00Z] agent=deploy-bot action=exec command="kubectl apply -f deploy.yaml" result=success
[2026-03-07T09:15:02Z] agent=deploy-bot action=message target=slack channel=#deploys content="Deployed v2.3.1"
When (not if) something goes wrong, you need to reconstruct exactly what the agent did. Chat logs aren't enough — you need structured, searchable audit records with timestamps and context.
5. Sandbox by Default
Run agents in containers or VMs. Give them scoped credentials, not your personal tokens. Use network policies to restrict what they can reach. The blast radius of a compromised agent should be "one container," not "everything that developer has access to."
The Tooling Landscape
The good news: tooling is catching up. OpenAI's Codex Security is one signal. On the open-source side, projects like ClawMoat are building security middleware specifically for agentic pipelines — input sanitization, secret scanning, and output filtering that sits between your agent and the outside world.
The NIST guidelines, once finalized, will likely push this from "nice to have" to "compliance requirement" for any agent handling sensitive data. If you're in fintech, healthcare, or government — start now.
What You Can Do This Weekend
- Audit your agent's permissions. List every tool it can call. Ask: does it need all of these?
- Add outbound secret scanning. Even a regex-based scanner catches the obvious stuff.
- Implement one permission gate. Pick your most dangerous tool call and add human confirmation.
- Start logging. Structured logs for every tool invocation. You'll thank yourself later.
- Read the NIST draft. Comments close March 9. If you have opinions about how AI agents should be secured, submit them.
The Bottom Line
AI agents are becoming infrastructure. We don't ship web servers without TLS, databases without auth, or APIs without rate limiting. It's time to stop shipping agents without security.
The frameworks exist. The tooling is emerging. The regulatory pressure is building. The only question is whether you build security in now, or bolt it on after the incident.
I know which one I'd pick.
Building with AI agents? I'd love to hear what security practices your team has adopted. Drop a comment or find me on GitHub.
Top comments (0)