events

AgentMinder and the Problem Your IAM System Wasn't Built For

An autonomous agent doesn't fit the user model or the service account model. Broadcom's answer gives agents identities, missions and runtime policy, and routes every action through a gateway that checks intent before execution.

Your identity infrastructure knows about three kinds of thing. Users, service accounts, and applications. An AI agent acting on your behalf doesn't fit any of them.

A user is a person with credentials and a session. A service account is a fixed identity with a fixed permission set. An agent has a goal instead of a permission set. It decides at runtime which tools to call and which data to read, and its behaviour shifts with context. Give it a static role and you either grant too much or stop it doing the job.

AgentMinder is Broadcom's answer, announced on the opening day of Explore 2026 alongside a wider security package for agentic workloads. It was one of seven announcements that landed on 31 August, and one of the two that dealt with governing agents rather than running them.

What it does

Agents get four things: an identity, a mission, a set of authorised tools, and runtime policies. Identity and tools are familiar. Mission and runtime policy are the new parts, and they're what make it fit the problem.

Enforcement runs through a cloud-native runtime gateway. Before each invocation the gateway checks four things against the execution context. The agent's identity. Whether it's authorised for the tool it's reaching for. Its declared intent. And the data sources it's targeting.

Checking before every invocation is the significant design choice. This isn't a permission granted at session start and trusted afterwards. Each action gets evaluated in context, which is the only model that works when the actor picks its own next step.

The audit trail

AgentMinder writes to OpenTelemetry, producing machine-readable audit records for every agent interaction. Broadcom describes it as a verifiable chain of custody, with operational telemetry and automated anomaly detection across multi-agent workflows.

If you work in a regulated environment this is the part to pay attention to. The question a regulator eventually asks about an autonomous agent isn't whether it was secure. It's whether you can reconstruct what it did and why. “The model decided” won't survive an operational resilience review. A per-invocation record with declared intent attached might.

Using OpenTelemetry rather than a proprietary format was the right call. The agent audit trail lands in the same observability pipeline as everything else instead of becoming a separate system nobody opens.

The network layer

vDefend picks up agentic-specific capabilities alongside AgentMinder. Three worth naming.

• Identifying agentic AI components by continuously monitoring traffic flows. You can't govern what you haven't found, and in most estates agents show up before anyone approves them.

• Detecting unauthorised shadow AI. Same discovery problem, stated as a control. It will find things.

• Distributed virtual patching using AI-generated IDPS signatures. Read this one carefully. AI-generated signatures with distributed enforcement is a real capability, and also one where I'd want to understand false-positive behaviour before switching it on estate-wide.

Avi adds API protection and lateral security for agentic traffic, which connects to the MCP session handling and tool RBAC work covered earlier in this series.

The gateway principle

Purnima Padmanabhan, who runs Broadcom's Tanzu Division, stated the design rule plainly in the briefing. You never give agents direct access to anything. Everything goes through the gateway. Agent to model, agent to skills, to tools, to data products, with multiple gateway layers and security added at each one.

That's worth adopting as a rule whatever tooling you end up using. Direct agent access to a data source is the agentic version of an application with a hardcoded database password. It works fine, right up until it's the thing you're explaining in an incident review.

What this means for design

• Agent identity is a new identity class and it needs an owner. Decide whether that sits with IAM, the platform team, or somewhere new. The wrong answer is nobody.

• The gateway is a chokepoint. Everything routing through it makes capacity, latency and availability design concerns rather than deployment details.

• Discovery comes before governance. Run traffic monitoring before you write policy. The number of agents already running in your estate probably isn't zero and probably isn't documented.

• Map the audit output to your regulatory obligations. Chain of custody for agent actions is a useful control narrative for CPS 230 and similar frameworks, but only if somebody does the mapping.

• Declared intent is a design artefact. If agents declare intent and the gateway checks it, then the intent taxonomy is something your team defines. That's a design decision hiding inside a product feature.

Most estates have no agentic AI policy at all. The tooling arriving is a reason to start writing one rather than a substitute for having one.