Tanzu, AgentMinder, and the Difference Between a Bind and a Grant

I have been working tirelessly in my environment lately.

Until now, everything I have been doing in the lab was spit and gum. Building my own things, wiring my own agents, hand-rolling the connections between them. It works, and I have written a lot about what it taught me: VCF lab deployment, Nemo vs. Hermes: The Track to Get My Agent to Stop Lying to Me, shared memory and identity. But I felt like it is time to start working with an actual enterprise platform, because that is what I do for a living. I work with companies building agentic AI platforms that are supposed to solve real problems instead of running on spit and gum. At some point I had to go build the thing I keep telling other people to build.

Everything here runs in my own home “enterprise lab”, and I am writing in a personal capacity. None of this is done as a Broadcom employee or on behalf of Broadcom.

This is a significant change. Here is the architecture of my current estate.

An actual company, with departments

What I have created is, structurally, a small company. Two departments so far.

One is IT, where most of my focus is. Agentic AI for AI-ITOps, the thing this whole blog has been circling around for months, basically agents running your private cloud ops, platform ops and devops. The other is the business side. In this case, marketing research and marketing execution.

Two systems work together to make this run:

Tanzu, a PaaS that is now also an agentic platform, where you build and run agents using Pydantic or any other framework of your choice. I used the built-in Pydantic. You just push your code or your intent and the system builds it for you, with no need to hand tailor a whole build / test / run operation. This is also where you build and run MCP servers and connect other essential services such as LLMs, on and off prem, webhooks and so on, all through the easy-to-use marketplace.

That marketplace is also the first place you can shut access off, and it is the control people skip. Lloyd Woodroffe, the PM on this, pointed out that marketplace visibility is itself scoped per org. An org can be limited to seeing and binding only certain services in the first place, which means access can be shut off structurally, before an agent, a bind, or a grant is ever involved. It is blunt next to the per-agent grants I get to later in this post, and it is no substitute for them: no per-agent identity, no live revoke. But it is a lever, and worth using deliberately. If a research org has no legitimate reason to touch VCF, a clean control is to make VCF invisible to that org’s marketplace.

AgentMinder, a newly announced platform from Broadcom, which controls access to MCP resources, which in my case run on Tanzu. It puts a gateway in front of everything: agents register with it, MCP services register with it, and grants and access are controlled by identity through that gateway. It also has agentic observability, where you can see who got access to what, and which agent got denied and when. That is a very important aspect of any governance system.

These are identities, not people. There is no directory behind them and nobody logs in as one. Each of my agents is registered here as its own thing, which is what makes the next part possible.

Where the agents actually run

I have agents running on Tanzu itself, as Tanzu agents. Here is how my infra management agent looks.

I also have agents on Kubernetes. My infra and platform management agents manage their own platforms, which right now means the VCF environment, the Kubernetes clusters, and the Tanzu platform itself. All of it is done through MCP servers.

I built MCP access for all of them, and all of it runs on Tanzu. I will record a proper demo later, I have not had time to put a video together, but this is what I am actually doing.

The MCP server is what provides the tools. Imagine a VCF MCP server giving access to vCenter, to vROps, to information and actions across VCF. There is a Kubernetes MCP that does the equivalent on Kubernetes, any action, any piece of information, wired straight into my environment.

The genuinely nice part of Tanzu is how you give an agent access to any of that, or to an LLM, or to any other service. You bind it.

It is fast. You can bind anything in the marketplace to anything that needs it.

Lloyd also pointed out something worth explaining properly. When you bind, what Tanzu is actually doing is injecting the service’s credentials straight into the app’s environment variables, at deploy or restart time. Whatever the service is, a database, an LLM, an MCP server, the bind resolves down to the same mechanism: Tanzu writes a connection string or a key into the app’s environment, and the app reads it out like any other config value.

Once you see it that way, the rest of this post makes more sense. The bind is a one-time credential handoff, not an ongoing decision. The platform hands the app a secret and then steps back. From that moment on, the app has the credential in its own environment, and nothing about the bind itself governs what the app does with it afterward. That is precisely the gap a grant has to fill, because the bind mechanism was never designed to.

A bind is not a grant

This is the main idea in this post. Not only how easy it is to build an agent and give it what it needs on a PaaS like Tanzu, which is the bind, but also the governance, which is the grant.

Two systems with two missions very complementary to each other. Tanzu builds, runs, deploys and provides a way to control what exists for an agent to reach. So IT has access to VCF management while Research has access to a whole harness of web search and file management, while AgentMinder decides what an agent is actually permitted to do once the tool is there. Wiring a door into a running agent is a Tanzu problem. Deciding whether anyone may walk through that door, and which tools they may use once they are through, is an AgentMinder problem.

I can bind any service in the marketplace to any agent. My agents each live as their own thing, and I talk to them separately too. A chat for the infra agent. A chat for the marketing agent. One for the Tanzu agent, one for the Kubernetes agent. Each of them can go into the marketplace and pick whatever they are allowed to pick.

Here they are on different doors. VCF, Tanzu, and the research harness. Not the same MCP with a different grant. A different MCP for a different job.

It may seem overlapping. Tanzu gives you a first layer of governance right there, through the marketplace and what is provided to your agents. You can see, cleanly, exactly which tools exist for an agent.

And then AgentMinder adds the layer of identity, governance and observability.

The way it works is that every agent gets a bearer token from AgentMinder. Something close to a login. And whatever that token has a grant for is what the agent can actually touch, regardless of what it is bound to. I can bind an agent to an MCP service in Tanzu and still have certain tools in it denied at AgentMinder. The bind gets you visibility and connectivity. The grant is what decides whether anything happens.

This is what a grant actually looks like. Two roles on the same MCP door, vcf-mcp. Same server, same bind, different permission.

Look at the intents column. vcf-mcp-full can call vcf_call, the tool that reaches any VCF API. vcf-mcp-read cannot. Nothing about the bind changes between those two roles. The agent is wired to the same MCP server either way. The only thing that moves is which role its identity is assigned to, and that is the whole argument of this post in one screen.

Compare that with the bind screenshot earlier in this post. The bind screen has a button that says BIND SERVICE. It does not have a column for what you are allowed to do once you are bound, because that is not the question it answers.

Here is the platform agent, granted access to Tanzu but not to Kubernetes, correctly refused when it tries.

And here it is granted for VCF broadly but blocked from a specific action inside it. You can see on the right side of the screenshot that it actually has the correct MCP, and it is still denied.

A bind is a connection. A grant is a decision. Every PaaS platform I have seen makes the first one easy, though Tanzu is the only one I know that provides such a level on prem, but very few make the second one real, and the ones that do not are the ones where “governance” turns out to mean a diagram nobody actually enforces.

Here is the whole estate answering that question at once. Every agent was asked for a tool it holds, then a tool it does not.

The pair worth mentioning here is Platform Look and Platform Run. They point at the same MCP server. One can list things, the other can also act. Nothing about the bind is different between them. The only difference is the grant.

Two things I learned the hard way

Getting a grant to actually mean something took more than turning the feature on. I broke it twice while building this.

The first time, my agents could walk around the gateway entirely. When I first wired everything up, some of my apps talked to the MCP servers directly instead of through AgentMinder’s gateway. The bind worked, the tool calls worked, and none of it ever touched the thing that does the permission check. Governance was fully configured and completely irrelevant, because the traffic had another way in. The fix is simple to state and easy to skip: every application has to be wired so the gateway is the only path to an MCP resource, with nothing left reachable directly. If an agent can reach a tool without going through the gateway, it will, and it will never even know it did something wrong. This is where L4 security, for example, can help. Good old micro-segmentation will block any route to the MCP server that does not go through the gateway.

The second time was subtler. I revoked a grant on a live agent, waited well past the token’s expiry, and it kept working. Same question, same correct answer, grant gone. The reason was a leftover static key, sitting right next to the gateway URL in the app’s own configuration, left over from before I had the real path working. The agent had a second, permanent way to authenticate that had nothing to do with the identity AgentMinder issues and expires. Revoking the grant never touched it, because the grant was never what the agent was actually using, it was using the master key.

So here is the rule I would teach anyone doing this: the gateway has to be the only door, and the only key that opens it has to be the one the gateway itself issues. No direct routes to the MCP servers. No standing credentials sitting in an app’s config as a leftover or a shortcut. The moment either of those exists, governance is a diagram again, not a control, and the only way you find out is by testing the revocation, not by trusting the grant screen.

Both of my failures had the same shape: the agent held something durable of its own. So I stopped letting it hold anything. AgentMinder ships a sidecar for exactly this, and every agent now runs one beside it. The agent’s configuration points at 127.0.0.1 and nothing else. It has no gateway address and no key. The sidecar next to it proves who the agent is, gets a token that expires in sixty seconds, and calls the gateway. If you copied everything the agent knows, you would have a loopback address.

That is what makes the second failure impossible rather than merely fixed. There is no longer a second way to authenticate, because there is nothing durable to authenticate with.

Which finally let me run the test I should have been able to run the first time. I took a grant away from a live agent, mid-session, and did not touch the app at all. No restart, no redeploy, no reconnect.

About ninety seconds later, which is the token expiring, it politely refused. I gave the grant back and it answered again. That gap is the honest cost of short-lived tokens, and I would rather explain a ninety second delay than explain why a revoked agent is still working.

One more thing I only found because I went looking for it. Early on, a tool the agent was not granted still worked when I called it by name. The gateway had been filtering that tool out of the menu it advertised, but it was not refusing the call. Hiding a tool is not the same as refusing it, and a demo that only ever clicks the allowed button will never tell you the difference. Turning on per-call policy enforcement is what closed it.

What this actually buys me

I spent a long time in my own spit-and-gum factory learning exactly how hard this is to do properly. Now, with Tanzu and AgentMinder, I can do it the private AI in the enterprise way:

• register MCP services
• register LLMs
• build agents quickly and cleanly
• state intent and have it built
• consume as much of the marketplace as I need
• express identity per agent
• control access through the MCP servers, by identity, not by convention

If I were running this at an actual enterprise, I would be using a platform like this without hesitation, rather than going the build-your-own route. Build-your-own is always messy, no matter how careful you are. I know, because I have been doing it in public on this blog all year. And everyone who builds their own ends up doing it their own way, which means nobody’s lessons transfer and every team rediscovers the same failure modes from scratch.

As soon as I have some time to record the demo, I will put it here.

More on this as it develops.