TL;DR: Your security team is probably the first team in the company running AI agents in production. Seven client calls between June 4 and August 18, 2026 showed the same shape: security builds agents for its own work while it writes rules for everyone else. Govern those agents first. They're the fastest, cheapest proof that your rules work.
A senior security engineer at a medical device company told me on August 18, 2026 that he'd sat through 8 to 10 vendor pitches in six months. In each one, the thing he'd built himself met or beat the product. His agents triage every ticket from the security monitoring system. A threat intel scraper runs every other hour and scores what it finds.
He said he treats his agents like a junior analyst. Here's weird, here's standard.
The part I keep chewing on is that the same team writes the AI rules for the rest of the company. Their own agents got there first.
Key takeaways:
Seven client calls between June 4 and August 18, 2026 showed security and compliance teams running AI agents on their own work before the company had rules for anyone.
One security director at a hardware company was asked by the CIO to train other departments on AI, because security was the only team that had done it well.
A medical device company's security builder found his own agents met or beat the vendor product in 8 to 10 sales calls over six months.
The junior analyst frame works: an agent starts with narrow scope and a human who checks its output, then earns more.
The agents your own team runs are the best place to test an owner, a tool list, a log, and a stop switch before you ask the sales team to accept them.
Why is the security team usually the first to run AI agents?
Security teams live in tickets, logs, questionnaires, and vendor forms. That work is repetitive and text heavy. It's the exact shape an AI agent handles well. So security builds one. Then the compliance team next door does the same for evidence gathering. Everyone skips the policy step, because the pain is theirs and the fix is an afternoon of work.
I run four agents in Josh's Lab on a Mac Studio. Scout does research and Forge writes code. I built them for the same reason the engineers above did. The work was mine and it was boring.
On an August 5, 2026 call, a security director at a hardware company told me his team runs agents in production. The CIO noticed and asked security to train the other departments. He's already run one-hour sessions for the people team and for marketing. The job found him, because his team was the only one with something that worked.
That's the pattern. Security is the first adopter and the governor at the same time. Few teams say that out loud.
How often does this come up on client calls?
Seven times between June 4 and August 18, 2026, across companies that share little else.
June 4, 2026. A ratings agency's security team assesses new MCP servers by pasting the details into ChatGPT and asking what could go wrong. Then they decide in a meetup. MCP is the Model Context Protocol, the plug that lets an AI agent call tools.
June 8, 2026. A healthcare company's compliance team runs Codex agents wired into Confluence and Jira, where their policies live, to run their own processes. They planned a July offsite around it.
July 6, 2026. A large insurer's risk office reported a recurring internal ask: where can AI help us do our own job.
July 20, 2026. An investment bank was already running an AI code reviewer, a model that approves code changes, before they asked me about it.
August 5, 2026. The hardware company above. Security runs production agents and got drafted to teach everyone else.
August 11, 2026. An insurer where 75% of the company reaches AI through one front end the security team runs, with almost every frontier model behind it.
August 18, 2026. The medical device company. Autonomous triage on every ticket and a scraper on a two-hour loop.
Six of those seven teams are the ones who'd normally write the AI policy. They wrote code first.
What's the risk when the governors go first?
The risk is that the security team's agents get a pass. The team knows the agents. It trusts them. So the rules the team wrote for everyone else stay on paper at home. Then a security agent with broad read access to every log does something odd, and there's no owner on paper, no tool list, no log line that says which agent did it, and only the builder knows how to stop it.
I've done this in my own lab. Scout, my research agent, once handed me a set of citations that looked perfect. Right format, real-looking sources. Every one was invented. Its output went straight into other work, unchecked, because I'd built it and I trusted it. Hours of downstream decisions went back in the bin.
The medical device engineer named the same failure in his own words. Some days he's collaborating with the agents. Other days, his phrase, he's swearing at them.
A trusted builder skips the check because the builder is trusted. That's the whole problem. The fix is to apply the rules to your own agents first, before the trust builds up. I laid out the ownership side in every AI agent needs one accountable human, and it applies to the agent the security team built on a Friday afternoon just as much as to a vendor's.
What does governing your own agents first look like?
Treat the security team's agents as the pilot for the whole company's rules. Four things, applied to every agent your own team runs, this month.
One named human owner. The engineer who built it. If he leaves, the agent is reassigned or shut off that week.
A written tool list. Which systems the agent can call. The ticket queue, yes. The firewall config, no.
One log line per action, attributed to the agent rather than the human who launched it. If the security monitoring system lumps the agent's calls in with the engineer's, that's the first fix.
A stop switch someone other than the builder can pull. If the only person who can stop the triage agent is the person who wrote it, you don't have a stop switch. You have a hobby.
This is the same shape the Agentic Trust Framework asks of every agent. It's five questions: who are you, what are you doing, what are you eating and serving, where can you go, and what if you go rogue. The full text is public at the Agentic Trust Framework, published by the Cloud Security Alliance on February 2, 2026. Ask those five questions of the ticket-triage agent before you ask them of the finance team's.
The junior analyst frame the medical device engineer uses is the right autonomy model too. A junior analyst starts with a narrow queue and a senior who reads everything. Trust grows with a track record. An agent should climb the same ladder, and your team's own agents are where you learn what the rungs look like. I covered the review side of that ladder in who approves the code your AI agent wrote.
Why does this make the rest of the company easier to govern?
Because you'll have proof instead of a policy. When the sales team asks why their agent needs an owner and a tool list, you show them yours. Here's the triage agent. Here's its owner. Here's the log. Here's the stop switch and the name of the last person who pulled it. That lands harder than a PDF policy.
The hardware company's security director found this out by accident. His team's working agents made him the trainer for the whole company. It happened because working proof beats a written rule every time.
There's a second win. Your own agents will fail in small, cheap ways first. The ratings agency's ChatGPT-based MCP review will miss something. The code reviewer at the bank will approve a bad change. Each miss teaches you where the rules need a line that's missing. Better to learn that on a ticket queue than on a customer refund flow.
The security team already runs the agents. Governing them first costs a week. Skipping it costs the credibility of every rule you write after.
Frequently asked questions
Should the security team stop building its own AI agents until there's a policy?
Keep building. The work is real and the pain is theirs. Put the four controls on what you've already built (owner, tool list, attributed log, stop switch) and write the policy from what you learn. A policy written before anyone has run an agent describes an imaginary thing.
What if the compliance or risk team built agents before security did?
Same answer. Whoever built first governs first. On June 8, 2026 a compliance team had Codex agents running in Confluence and Jira and was still learning as it went. Skip the fight over who owns the rules. Put the four controls on that team's agents and use them as the example.
Does an agent that only reads logs really need a stop switch?
Yes. Read access to every log is a lot of access. A triage agent that reads tickets can also read the customer data inside them. The stop switch exists for the day the agent does something else. If only the builder can stop it, the whole company depends on one person's login.
How do you tell a security engineer's agent from the engineer in the logs?
Give the agent its own identity and its own credentials, separate from the human who launched it. Then every call the agent makes carries the agent's name. Without that, the log says the engineer did it, and you'll spend a morning proving it was the agent.
Is this the same as shadow AI?
It's the version of shadow AI that lives inside the security team. Shadow AI is employees using AI tools without the company knowing. Security's own agents are usually known, just ungoverned. That's easier to fix, because the builders and the enforcers sit on the same team.
Every rule you write for the company will be tested against the agents your own team built. Govern those first, or expect the rest of the company to point at them.