Skip to content
HANU
Deploy Hanu
Menu

By role

Agents, tools and MCP servers

An agent is a workload that can be talked into acting. The security question is not what it is prompted with — it is what it is permitted to reach, and whether anyone still owns that permission.

MCP server securityAI agent securityagent tool permissions

The problem

An agent is given credentials because it needs to do a job, and those credentials are then broader than the job. It reaches tools registered by someone who has since changed teams, through a server that appears in no inventory.

Three properties separate this from ordinary service-account hygiene. Agents are long-running, so a credential that should have been short-lived stays valid. Their inputs are untrusted text, so the set of actions available to them is the real attack surface. And they multiply — one useful workflow becomes a dozen agents with overlapping permissions well before anybody reviews the list.

Every one of those properties is a permission problem wearing a machine-learning costume. Reach can be enumerated; prompts cannot.

How Hanu approaches it

The permission graph, not the prompt

Collection is organised around reach. Which identity does the agent run as. Which tools, APIs and data stores does that identity resolve to. Which of those touch a crown-jewel asset, and which sit one assumption hop away from one that does. Reach determines the blast radius of a successful manipulation, and unlike a prompt it can be enumerated, differenced and alerted on.

MCP servers are network services, so inventory them as such

An MCP server is a service an agent trusts and that can be replaced. Hanu treats registered servers as infrastructure: what is reachable, when it last changed, who owns it, and whether the tool definitions it advertises have broadened. Ownership is part of the record because a finding with no owner is a finding with no fix.

Agent identity is non-human identity

Agents are subject to the same questions as every other machine credential — age, rotation, unused permissions, and whether the credential has ever been used from somewhere it should not be. The full treatment is in non-human identity.

Agent exposure, by questionanswered from inventory and history
QuestionObservableSource
What does this agent run as?identity, key age, rotationcloud and IdP inventory
What can it reach?tool and data edges in the graphresource discovery
Is its tool set stable?served tool definitions over timeMCP endpoints you register
Has it done anything new?first-use and unusual reachsignal history

What you get

AG-01Tool and data reach, per agent
The edges between an agent's identity and the resources it can act on, scored for crown-jewel reach rather than counted. Reach is the number that decides how loudly to react.
AG-02MCP inventory with ownership
Registered servers, who owns each one, when it last changed, and the tool definitions it has advertised over time — so a definition that broadens is a diff rather than a discovery.
AG-03Credential hygiene for agents
Age, rotation and unused reach for the identities agents run as, folded into the same non-human identity view as service accounts, CI tokens and API keys. One queue, not four.
AG-04Anomalous reach without a tuning exercise
An agent exercising a permission it has never used, particularly against a sensitive resource, is a first-use signal. It needs no baseline period and no threshold argument, which is what makes it deployable on day one.

Limits

This is permission and usage telemetry, not prompt inspection. Hanu does not read agent instructions, tool arguments or model outputs, so it cannot tell you what an agent was asked to do — only what it was able to do and what it actually reached.

MCP coverage depends on the server being connectable and enumerable. A local stdio server running on a developer's laptop is not visible to cloud collection. If it needs to be in inventory, it has to be registered somewhere the platform can read.

There is no policy engine and no runtime blocking. The platform produces a ranked risk with an evidence trail; enforcement stays in the identity provider, the gateway or the agent framework, where the request can actually be denied.

Agent frameworks differ too much for a single connector story, and we are not going to pretend otherwise. Inventory is assembled from what the cloud account and the identity provider expose, which is a real constraint on completeness.

Questions

Do you need access to our agent framework?
No. Most of the useful facts are already in the cloud account and the identity provider: which principal an agent runs as, what that principal can reach, and what it has actually done. A framework-specific connector adds detail rather than providing the foundation.
How is this different from a service inventory?
An inventory lists what exists. This keeps the edges — which identity resolves to which tool which resolves to which datastore — and re-evaluates them when any part changes, so blast radius is answerable after a change instead of before one.
Can you detect a poisoned MCP server?
We detect that the tool definitions a server advertises have changed, and what they gained. Whether that change is malicious is a judgement for the owner of the server, which is exactly why ownership is part of the inventory rather than an afterthought.
Does analysing agent behaviour require an LLM?
No. Reach, first-use and change detection are graph and history operations over typed signals. The platform's detection and scoring path contains no model at all, which is why the same inputs produce the same risk every time.

Run it in your own account

One Docker Compose stack, your datastores, read-only credentials into your clouds. The Community edition is free to run in production.

Deploy HanuSee what is paid