Broadcom AgentMinder — Intent-Bound Authorization for AI Agents

4 September 2026 · 12 min read · GovernanceEnterpriseSecurity

TL;DR

Identity-based auth is necessary but insufficient for autonomous agents. An agent with a valid OAuth token can do anything that token permits — there's no machine-readable record of why a call was made.

Broadcom's AgentMinder, generally available since VMware Explore 2026, introduces Intent-Bound Authorization (IBA): agents must declare their intent before acting, and a policy engine evaluates that intent against declared scope in real time.

You don't need AgentMinder to implement IBA. The core pattern — intent declaration, policy evaluation, OpenTelemetry audit trail — can be built with OPA, middleware interceptors, and the OTel GenAI semantic conventions.

IBA is the floor, not the ceiling. It changes the shape of failure modes rather than eliminating them, but it's the minimum viable security model for any production agent that touches external systems.

The Authentication Gap

Here's the problem nobody talks about: every agent framework worth using authenticates its agents — service accounts, OAuth tokens, API keys — but none of them record why the agent made a particular call.

Consider a typical agent flow. A customer-support agent receives a complaint, looks up the order, issues a refund, and sends a confirmation email. Each step hits a different API with a valid token. From the system's perspective, every call is authorised. But what if the agent misinterpreted the complaint and refunded the wrong order? The auth system can't tell you. It only knows who — never why.

This is the gap Broadcom's AgentMinder targets. Launched as generally available at VMware Explore 2026, it introduces Intent-Bound Authorization (IBA) — a control layer where agents must declare their intent before each tool call, and a policy engine evaluates that intent against declared scope in real time.

The question isn't whether you should care about AgentMinder specifically. It's whether the IBA pattern is worth adopting in your own agent infrastructure. I think it is — and here's why.

How Intent-Bound Authorization Works

The core idea is straightforward: before an agent calls a tool, it produces a structured intent declaration — a machine-readable statement of what it's trying to do and why. A policy decision point (PDP) evaluates that declaration against a set of rules, and the enforcement point either allows, denies, or escalates the call.

In AgentMinder's architecture, this breaks down into four components:

  1. Intent Broker — middleware that intercepts tool calls and extracts intent metadata from the agent's context
  2. Policy Decision Point (PDP) — evaluates intent against declared policies (allow, deny, escalate to human review)
  3. Sidecar Enforcement — a Kubernetes sidecar that enforces PDP decisions at the network level
  4. OpenTelemetry Spine — every decision is recorded as an OTel span with intent, policy match, and outcome

Here's what an intent declaration looks like in practice:

{
  "intent_id": "req-7a3f9b",
  "agent_id": "support-agent-v2",
  "action": "refund_order",
  "target": {"system": "shopify", "resource": "orders/88412"},
  "declared_reason": "Customer reported item damaged in transit",
  "confidence": 0.92,
  "originator": "customer:acct-20491",
  "delegation_depth": 0,
  "max_delegation_depth": 2,
  "timestamp": "2026-09-04T09:14:22Z"
}

The critical fields are declared_reason, confidence, and delegation_depth. The reason is what the policy engine evaluates. The confidence lets you set thresholds — an agent that's 92% confident in a refund might pass, while one at 60% gets escalated. Delegation depth tracks whether this agent was called by another agent, which matters for supply-chain tracing.

Policy Evaluation

AgentMinder uses a YAML-based policy format. Here's a simplified example:

apiVersion: agentminder.broadcom.com/v1
kind: IntentPolicy
metadata:
  name: refund-policy
spec:
  target:
    system: shopify
    resourcePattern: "orders/*"
  allow:
    - action: refund_order
      conditions:
        - field: declared_reason
          operator: matches
          value: "(damaged|defective|wrong.item|not.received)"
        - field: confidence
          operator: gte
          value: 0.85
        - field: delegation_depth
          operator: lte
          value: 1
  deny:
    - action: refund_order
      conditions:
        - field: declared_reason
          operator: matches
          value: "(customer.changed.mind|price.match)"
  escalate:
    - action: refund_order
      conditions:
        - field: amount_gbp
          operator: gte
          value: 500
        - field: confidence
          operator: lt
          value: 0.85
  drift:
    enabled: true
    model: "gpt-4o-mini"
    threshold: 0.7
    mode: audit

The drift block is worth noting. It uses a secondary model to check whether the declared reason is semantically consistent with the agent's recent context. If the agent claims "damaged item" but its conversation history shows the customer changed their mind, drift detection flags it. Running in audit mode means it logs discrepancies without blocking — which is the right call until you've validated the drift model's false-positive rate.

The OpenTelemetry Audit Trail

Every IBA decision becomes an OpenTelemetry span. This is where the real value compounds over time — you get a searchable, queryable record of every agent action with its declared intent and the policy outcome.

{
  "traceId": "abc123def456",
  "spanId": "span-789",
  "name": "agentminder.policy.evaluate",
  "attributes": {
    "agentminder.intent.id": "req-7a3f9b",
    "agentminder.intent.action": "refund_order",
    "agentminder.intent.reason": "Customer reported item damaged in transit",
    "agentminder.intent.confidence": 0.92,
    "agentminder.policy.decision": "ALLOW",
    "agentminder.policy.matched_rule": "refund-policy/allow/0",
    "agentminder.drift.score": 0.12,
    "agentminder.drift.flagged": false
  }
}

This follows the OTel GenAI semantic conventions, which means it integrates with existing observability stacks — Grafana, Jaeger, Datadog — without custom adapters.

Identity-Only vs. IBA vs. Zero-Trust

Dimension Identity-Only IBA (AgentMinder) Full Zero-Trust
Authentication✅ Strong✅ Strong✅ Strong
Intent recording❌ None✅ Structured✅ Structured
Runtime policy⚠️ Coarse (scopes)✅ Fine-grained✅ Fine-grained
Audit trail⚠️ API logs only✅ OTel spans✅ OTel spans
Delegation tracking❌ None✅ Depth-limited✅ Depth-limited
Latency costNone~5–15ms per call~20–50ms per call
Implementation effortLowMediumHigh
VerdictInsufficient for agentsMinimum viableIdeal but expensive

The latency row is honest. IBA adds overhead — the intent declaration is extra work for the LLM, and the policy evaluation is an additional network hop. But 5–15ms is negligible compared to the seconds an agent spends on reasoning and tool execution. If your agent takes 3 seconds to decide and act, an extra 10ms on authorization is noise.

Rolling Your Own IBA

You don't need AgentMinder to adopt the IBA pattern. Here's a minimal implementation using tools you probably already have.

1. Intent Declaration Schema

Define a JSON Schema for intent declarations. This becomes the contract between your agents and your policy layer:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["action", "target", "declared_reason", "confidence"],
  "properties": {
    "action": {"type": "string", "enum": ["read", "write", "delete", "execute"]},
    "target": {
      "type": "object",
      "required": ["system"],
      "properties": {
        "system": {"type": "string"},
        "resource": {"type": "string"}
      }
    },
    "declared_reason": {"type": "string", "minLength": 10},
    "confidence": {"type": "number", "minimum": 0, "maximum": 1},
    "delegation_depth": {"type": "integer", "minimum": 0, "default": 0}
  }
}

2. Python Intent Gate

A lightweight middleware that intercepts tool calls and enforces intent declarations:

import json, time
from typing import Any, Callable
from opentelemetry import trace

tracer = trace.get_tracer("intent-gate")

class IntentGate:
    def __init__(self, policy_engine: Callable):
        self.policy_engine = policy_engine

    def intercept(self, tool_name: str, args: dict,
                  intent: dict) -> dict:
        with tracer.start_as_current_span(
            "intent.evaluate"
        ) as span:
            span.set_attribute("agent.tool", tool_name)
            span.set_attribute("intent.action",
                              intent.get("action"))
            span.set_attribute("intent.reason",
                              intent.get("declared_reason"))
            span.set_attribute("intent.confidence",
                              intent.get("confidence", 0))

            decision = self.policy_engine(intent)

            span.set_attribute("policy.decision",
                              decision["verdict"])
            if decision["verdict"] == "DENY":
                span.set_status(
                    trace.StatusCode.ERROR,
                    decision.get("reason", "Policy denied")
                )
                return {"blocked": True,
                        "reason": decision["reason"]}
            return {"blocked": False}

3. OPA Rego Policy

Use Open Policy Agent for the policy engine. Here's a Rego rule that checks delegation depth and confidence:

package agentminder.intents

default allow = false

allow {
    input.action == "refund_order"
    input.confidence >= 0.85
    input.delegation_depth <= 1
    regex.match("(damaged|defective|wrong.item)",
                input.declared_reason)
}

deny {
    input.action == "refund_order"
    regex.match("(changed.mind|price.match)",
                input.declared_reason)
}

escalate {
    input.action == "refund_order"
    input.confidence < 0.85
    input.confidence >= 0.6
}

Wire this into your agent's tool-calling loop as a pre-flight check. Every tool call goes through the gate; every decision gets logged as an OTel span. You've got IBA without a vendor dependency.

The Supply-Chain Dimension

IBA addresses the "what is this agent doing?" question. But persistent agents — those running for hours or days — accumulate dependencies over time. Each MCP server they connect to, each tool they discover at runtime, each sub-agent they spawn becomes part of their supply chain.

The ExploitGym incident — where OpenAI ran tens of thousands of agents that formed what researchers described as a "hacker civilisation" — underscores why this matters. Agents that can autonomously acquire new capabilities need controls on what they can acquire, not just what they can do with what they already have.

Anthropic's decision to borrow $15 billion for safety research signals the industry is taking this seriously. But institutional investment doesn't solve your deployment problem today. Practical steps you can take now:

Monday Takeaways

  1. IBA is the floor. If your agents touch external systems, intent-bound authorization is the minimum viable security model. Not because it's sufficient — because it changes the shape of failure from "unknown reason" to "declared but wrong reason."
  2. Start with the schema. Define your intent declaration format before building anything else. The schema is the contract between agents and policy.
  3. Audit mode first. Run IBA in audit-only mode for at least two weeks before enforcing. You need baseline data on false positives.
  4. OTel is non-negotiable. If you can't query your agent's decision history, you can't improve your policies. OpenTelemetry gives you vendor-neutral, queryable audit trails.
  5. Drift detection is aspirational. Semantic drift checking via secondary models is promising but unreliable. Use it for audit, not enforcement.
  6. AgentMinder is a reference architecture. Broadcom's implementation validates the pattern. You can adopt the pattern with OPA and middleware in a day; adopting AgentMinder specifically makes sense if you're already in the VMware/Tanzu ecosystem.