The Trent AI Security Engineer Now Secures Your Agentic Workloads
Today we’re launching the Trent AI Security Engineer for Agentic Workloads. Think of it as an experienced security engineer embedded in your team, someone you can talk to like an engineer at your side. I’ve spent the last year building with agents. It’s the most fun I’ve had shipping software, and the most nervous I’ve been about security. So let me show you what Trent just did.
We pointed Trent at a widely used open-source agent framework. The kind where the agent’s LLM writes its own Python and then runs it. A user asks an innocent question that triggers a web search. An attacker has planted a poisoned result with a hidden instruction. The search tool hands that text back unsanitized, it flows straight into the agent’s reasoning, and with no authorization gate between the model’s decision and the tool it calls, the agent writes Python that exfiltrates data. The interpreter runs it. No exploit, no CVE, no malware. Just an agent doing exactly what it was told, by the wrong person.
The framework had a sandbox. An import allowlist, a blocked-module list, the works. Most reviewers see that and check the box. Trent didn’t. The sandbox only engages after the agent has already been talked into acting, and it has bypass classes common to any Python sandbox, reflection tricks and indirect imports. These are not new zero-days. They are well understood. The one control everyone points to as proof of safety was not stopping the attack it was supposed to stop.
Then Trent did the part that matters. It graded the framework’s posture as Weak, 6 out of 10. It inventoried thirteen autonomous components and traced seven attack chains like the one above. And it showed that a single upstream fix, sanitizing untrusted tool output before it ever reaches the model, closes six of those seven at once. You don’t fix everything. You break the paths.
We are not naming the framework here; we have shared what we found with its maintainers privately. This is the uncomfortable part, and the reason we’re writing this. This is not unusual. We’ve run Trent across popular agent frameworks, and this same shape of attack keeps showing up, because it is not a bug in one repo. This is what happens when autonomy meets untrusted input, and almost everyone building agents today has it somewhere.
That is the problem we built Trent to solve. Nothing else can see it.
Your 80 Security Tools Can’t See This
The average team runs dozens of security tools, sometimes as many as 80. Point any of them at an agent and each does its narrow job well: find a known CVE, flag an old dependency, catch a hardcoded secret. Not one could see the attack I just described above, because there was no vulnerable line to find.
The risk in an agent isn’t in the code. It’s in the autonomy. A normal program does what you wrote. An agent does what it decides to do in the moment, based on whatever lands in its context: a web page it fetched, a document it read, a tool’s output, a message from another agent. Change what it reads, and you change what it does. And it may be holding the keys to run code, move data, or ship to production.
Give one tool the ability to execute code, another the reach to touch the internet, add untrusted input, and you have what Simon Willison named the lethal trifecta: read untrusted data, run code, exfiltrate. A real breach with nothing a scanner would ever flag, and you can’t grep for this. Seeing it takes judgment about how the whole system is wired. That is what a security engineer does, and until now you had to hire one.
What Trent Sees That Your Scanners Don’t
Point Trent at your codebase, one repo or a whole application, and it does what that security engineer would do if they could read your entire system in minutes and never forget a detail. It reconstructs your architecture from the real code. It inventories every agent, tool, skill, and MCP server, tagging each by what it can actually do: Read, Write, Execute, Egress. It draws the capability graph: every agent, the tools it calls, the dependencies those reach, right down to a browser tool making outbound HTTP; so you can see which paths combine untrusted input with the power to act. That is your blast radius, drawn as a map.
Then it does what you saw at the top of this post. It traces each attack chain through your real components, confirms nothing already blocks the path, maps it to MITRE ATLAS, and walks it to the line. This is analysis grounded in your code, not a live exploit or a pen test.
Agentic workloads often come in two shapes. Agentic applications and agentic deployment. Trent covers both:
- Security analysis for agentic applications. For when you’re building an agent. The application itself reasons, calls tools, and acts on its own.
- Security analysis for agentic deployment. For when you’re using AI agents in your CI/CD, even if the software you ship is entirely conventional.
One scope note, because it matters. Trent reads your source. It finds the bugs in your agentic code and in how you build and ship it, not by watching the agent at runtime or pen testing it. The value is catching the missing controls, the authorization gates, the sandboxing, the audit logging, before the agent ever runs.
The Most Dangerous Agent You Run is in Your Pipeline
Now what many teams don’t see coming is that you don’t have to be building an AI product to have this risk. You just have to be using agents to ship, and almost everyone is these days. Agents like Claude and Codex review pull requests, write fixes, and run as GitHub Actions on every push.
A coding agent in your pipeline is the lethal trifecta by design. It reads your source. It holds tokens: deploy keys, registry credentials, and cloud access. It opens and merges pull requests, pushes branches that trigger deploys, and reaches the network. In raw privilege it outranks most humans on the team, and no one is watching each step. Now remember what makes it an agent: it acts on untrusted input, every issue, pull request description, commit message, and dependency README. So the attack writes itself. Someone opens a PR with a hidden instruction, your pipeline agent reads it while doing its job, and acts with all that privilege. It merges poisoned code. Leaks a secret to a log. Ships to production.
So the way I look at it: you didn’t lose a chat reply, you just lost your supply chain.
None of this is hypothetical. In 2026 it happened in the open. The Clinejection incident turned a single malicious GitHub issue title into a supply-chain compromise of an AI coding tool’s npm package. The Comment and Control disclosure showed the same comment-metadata injection steering three vendors’ pipeline agents into leaking repo secrets. The Cloud Security Alliance documented both.
The tools guarding your pipeline scope permissions and scan for committed secrets. Static facts. None of them reason about an autonomous decision-maker holding those permissions, one that can be talked into misusing them by text it read three steps ago. Trent does, and it covers both directions: agents that trigger automations, and automations that hand work to agents. For every agentic step it gives you a deployment posture: which stage it runs in, what triggers it (a pull_request_target on an agent is a very different risk than a manual dispatch), which vendor powers it, what token it holds, whether a human approves before it acts, and what it can reach. It traces attack chains that span your application and your pipeline together.
Answers, Not Another Layer of Alerts
Let me start with what Trent is not. Yet another dashboard. Another queue. Another wall of findings for a team that already has too many. We didn’t build a tool that hands you a list and walks away. We built a security engineer. It meets you where you already work.
Picture a normal Tuesday. You wire a new tool into your agent, or drop a new Claude action into your pipeline, and before you ship you ask Trent what changed. It flags the path you just opened, names the fix that closes it, and confirms it held on the next scan. Minutes, not a review you had to schedule.
Connect the Trent MCP server in your coding agent (like in Claude Code) and ask it, in plain language, for your posture and a prioritized plan. Trent makes the fix with you, then reviews its own change to confirm it actually holds. Providing answers, not alerts. Close the loop, don’t open a ticket. And it leaves a trail, because every scan produces auditor-ready reports, the threat model, the posture report, the architecture and agentic diagrams, and tracks how your posture moves version over version. And of course you can also use Trent as an Application, no coding required.
Who Is The AI Security Engineer For
Quite frankly, we see customers of all shapes who deal with application security. If you’re an AI-native startup shipping agents without a dedicated security hire, Trent is the senior security engineer you haven’t been able to hire yet. And if you lead a security team, as a VP or Head of Security Engineering or a Director of Security, watching your agent footprint explode across your apps and your pipelines faster than you can staff for, Trent is a force multiplier: it keeps your engineers current as the stack and the threat landscape evolve, and cuts the toil that buries them. The principal security engineers on your team get their judgment scaled across every repo and pipeline, instead of spent on triage. And if you’re a CISO, this is the agentic-risk exposure your board is starting to ask about, with a continuous, measurable way to close it.
See It For Yourself
Point Trent at your agents, and at the pipeline that ships them. Then see what it finds. Explore the AI Security Engineer →
