You know every service in your cluster by name. You know which team owns each one, what it talks to, how it scales, where its logs go. The agents are a different story.
That’s not a criticism, it’s an observation, and it’s one we keep running into. Every company we talk to is shipping agents of some kind, from scales of 10s to 1000s. Customer service bots that field tier-one tickets. Internal copilots that draft emails and summarise meetings and write the boring half of every PR. SREs that handle their own incidents at 2am while the team sleeps. What used to be a few experimental builds in a dev cluster is now dozens in some shops and hundreds in the biggest, growing faster than most teams are tracking.
That growth curve is the interesting part. Services tend to come into existence through a fairly heavyweight process. There’s a ticket, a design review, an owner, a runbook. Agents tend to arrive the way side projects do:
- Somebody had an idea on a Tuesday.
- By Friday it was in staging.
- At some point nobody can quite remember when it became part of the actual business.
Who said it could do that?
Pick an agent in your fleet, any one of them, and walk through what it actually has access to. Your email. Your customer data. Your prod APIs. Maybe a credit card on file for an internal tool. Maybe the ability to open pull requests. Maybe, somewhere, the ability to move money.
Then ask the second question: who, specifically, signed off on each piece of that access?
In the best-run teams I’ve talked to, the answers stay confident for the first few items and get quieter as the list goes on. In most teams, the quiet starts earlier than anyone would like.
A 3am story
Imagine it’s 3am, and an agent just paid a vendor.
You weren’t asked. The vendor wasn’t on the approved list. The token the agent used was valid, so nothing in the call path had any reason to stop it. The agent was doing exactly what the agent was built to do, which was to handle vendor onboarding without humans in the loop. It just decided that this vendor, on this Tuesday, was worth a payment.
Somewhere in your stack, there’s a log entry. You’ll find out on Monday. Hopefully.
Four questions
The way to think about the agent layer of your platform is the same way you’d think about the human layer. Four questions, and a platform that can’t answer them in real time isn’t ready for the agents that are already running on it.
Who is this agent? Not what’s it called, but what’s its identity. The thing a policy engine can reason about, the thing an audit log can attribute action to, the thing that survives a credential rotation. Names are nicknames. Identity is what you build governance on.
What is it allowed to do? Not in a README. In a policy that something actually evaluates at the moment of action. The README is the intention. The policy is the contract.
What did it actually do? Every call, every decision, every tool invocation, every delegation to another agent. Searchable, attributable, exportable. If the answer to “what happened at 2:47am” is “let me check the application logs,” the governance layer isn’t doing its job.
Are there agents in here you haven’t accounted for? This is the one that catches the most teams off guard. The unregistered side-project agent that someone shipped six months ago, the one that’s been quietly calling an LLM provider on the company card the whole time, the one nobody on the security team has ever heard of. You can’t govern what you can’t see.
Plenty of platforms can answer one or two of these. Far fewer of the teams we talk to can answer all four with confidence.
The gap between intent and behaviour
Here’s the part that tends to be under-appreciated: every agent has two sides.
There’s what the agent is allowed to do. The policy, the access list, the documented behaviour. And there’s what the agent actually does once it’s running, holding real credentials, talking to real systems.
Most platforms get a clear view of one side. They can tell you, with confidence, what the rules say. What they can’t always tell you — at least not without piecing together multiple dashboards — is whether the agent’s actual behaviour matches the rules. The gap between intent and behaviour is small most of the time, but the surprises tend to live there. Compromised credentials. Misconfigured tools. The model deciding, in some emergent way, that the right thing to do is something nobody anticipated.
The teams that handle this well treat intent and behaviour as two halves of the same picture and watch both.
Governance isn’t a feature
The pattern that keeps showing up in these conversations is that governance gets discussed as if it were a feature — something to bolt on once the platform proves itself, a check-the-box exercise for the security review before launch.
It’s not a feature. It’s a layer. It sits underneath the platform, and everything else sits on top of it.
For the human layer of every serious company, this is already true and has been for years. Nobody seriously argues that RBAC is optional. Nobody ships production without an audit trail. Discovery — the unglamorous work of finding the shadow IT that everyone forgot to register — has been a recognised category for two decades.
For the agent layer, almost none of this is settled. The early agent platforms are racing on capability, on benchmarks, on impressive demos. The governance question keeps getting filed under “we’ll handle that in the next release,” and the gap between what agents can do and what we can actually govern keeps widening.
There’s no good reason for the bar to be lower. Agents have more access, move faster, and make more decisions per minute than any human user ever did. If anything, the bar should be higher.
What’s next
This is half of the story.
The other half is what Tigera is building.
