The skillset of an "AI-native" product team is a moving target.
A few years back, prompt engineering was a hot skill. Then came context engineering, and agent engineering.
We still need to know all of the above. But we can’t put our feet up and call ourselves permanently AI-native.
The next layer is how to govern AI agent fleets: the ten or twenty agents already running across research, engineering, marketing, and documentation, as a team, with clear limits, under a human who is accountable on paper and, hopefully, responsible in reality.
I can think of no one better to explore this topic with than Chris Iljams, author of the ToxSec newsletter.
Chris holds an M.S. in Cybersecurity Engineering, is CISSP-certified, served in the USMC, and has hands-on experience from AWS and the NSA.
It’s safe to say he has encountered systems with rather more at stake than a broken workflow.
Chris also has a cool branded hat, which made me want one, except Product with Attitude would need a second hat for the last two words.
Today’s topic builds on some earlier groundwork. If you’re new to building agents, start with How to build your first agent or AI agent management and come back when you’re ready.
ToxSec’s words below.
Agentic Fleets Are Here. Product Teams Need to Learn How to Govern Them.
If you’re on a product team, chances are you’re already running multiple agents, from research to engineering to marketing to documentation. Good.
The more useful agents become, the more people on your team will keep building new ones. Even better.
That’s what successful adoption looks like.
But you have crossed an important line.
You have a fleet now. And fleets create a different category of questions. Which agents exist? Are they talking to each other? What systems can they access? Which tools can they use? Who owns them?
AI Agent Identity: Every Agent Gets Its Own Name and Permissions
Every AI agent needs its own identity and permissions. A shared service account makes attribution and revocation impossible.
We already solved a much simpler version of this problem with people. When someone new joins a company, we don’t hand them the password to a shared account called "employee".
They receive an identity, that identity gets permissions related to a role, and their actions can be attributed back to them. If they leave or change jobs, those permissions can be revoked.
Agents need something remarkably similar.
Agent Alice and Agent Bob should not secretly be sharing one enormous service account.
They should be Alice and Bob.
Once they have separate identities, a lot of useful things become possible. You can give them different permissions. You can see which one performed an action. You can disable Bob without firing Alice.
Send this to whoever owns AI governance on your team. Especially if nobody is quite sure who that is.