Governed agent tooling for enterprise AI operations
One governed toolset for an enterprise platform’s management surface, designed and operated by Humint Labs to make authority, tenant isolation and auditability executable.
- Delivery
- Designed, built and operated by Humint Labs as a governed toolset for an enterprise platform management surface.
Governed operating proof
Tools registered on a single governed server, spanning dozens of functional categories.
Two independent assistant vendors consume the same registration, with no vendor-specific fork of the toolset.
Governance and audit overhead per call, measured at the server, excluding the platform's own API time.
Read, configure and consequential. Every tool carries exactly one tier, declared at registration.
Measures describe the operating toolset and its request-path governance.
What your enterprise receives
A governed tool layer that lets agents act on enterprise systems without transferring authority, tenant isolation or auditability to the model.
Governed tool catalogue
Task-shaped tools organised around operational outcomes, with category and authorisation decisions made before release.
Authority model
Read, configure and consequential tiers that make the permitted action explicit for every tool.
Tenant isolation
Sessions and credentials bound to the caller’s authorised tenant, so cross-tenant reach is not a model decision.
Audit evidence
A durable record of caller, tenant, tool, authority tier, redacted arguments and outcome for every request.
Routing regression pack
Held-out operator requests that test whether agents select the intended governed outcome as the toolset evolves.
How Humint Labs gets it live
- Step 01
Map operations and authority
Define task outcomes, consequential actions, policy owners and tenant boundaries with the teams carrying operational risk.
- Step 02
Build the governed surface
Implement task-shaped tools, category structure, per-tenant access and request-path evidence around the target platform.
- Step 03
Operate and extend safely
Use routing regressions, audit review and tiered change control as new tools and assistant clients are introduced.
The operating challenge
An enterprise conversational AI platform keeps its management surface in an API. An assistant that can reach it can build and change production systems, yet the API does not decide which actions should be available, who may perform them or how the decision is recorded.
Exposing raw endpoints creates a surface no agent can use reliably and no security team can govern with confidence: neighbouring tool names, mixed levels of consequence, tenant reach that can become a model decision, and incomplete evidence of what occurred.
What we found
- Model context is the scarce resource, not endpoint coverage. A flat list of several hundred tool names spends the context budget before the agent has finished reading the task, and the failure it produces is not an error. It is a confident call to a neighbouring tool whose description also matched.
- Endpoint shape and task shape are different shapes. What an operator describes as one outcome, standing up a working conversational flow with its intents and its endpoint attached, is an ordered sequence of calls in the API. Tools drawn straight from the endpoint list push that ordering into the model, where it is guessed rather than enforced.
- The consequential operations are a small minority of the surface. Most of it reads. A smaller set writes, and a smaller set again is effectively irreversible against a live tenant: deleting a flow, restoring a snapshot over current configuration, removing a user’s access.
- Multi-tenancy was an isolation problem before it was a convenience problem. One operator legitimately holds credentials for several organisations, and one server process serves several operators. Anything that lets a tenant identifier travel as an ordinary tool argument makes cross-tenant reach a model decision.
- More than one assistant vendor was already in play, each with its own client behaviour around tool-name length, schema strictness and parallel calls. Building a toolset per vendor would have doubled the governance surface and given the two copies somewhere to drift apart.
Where the bottleneck sat
The constraint was never the API. It was that tool design is API design for a consumer that cannot read the documentation, cannot be trained on local conventions, and will make its best guess when two names are close.
Everything hard about this build follows from designing for that consumer.
Design rationale
Part of the answer was not code. Before any tool was written, the surface was sorted into three authorisation tiers, read, configure and consequential, and the list of consequential operations was agreed with the people who would carry the risk of it being wrong.
Which operations are consequential is a policy decision, not an engineering one. Writing the server first would only have encoded someone’s assumption about it faster.
Our Solution
Humint Labs designed and operates one Model Context Protocol server in front of the platform management surface. Tools are shaped around the outcome an operator needs, not the endpoint that happens to deliver it.
Each tool belongs to a functional category and carries one declared authorisation tier. Sessions are bound to a single tenant, credentials resolve from the caller identity and every call records the caller, tenant, tool, tier, redacted arguments and outcome.
The result is an operating surface where authority, isolation and auditability are built into how agents act.
Scroll diagram horizontally
Task-shaped tools
Tools are named and scoped by the outcome an operator wants, not by the endpoint that happens to deliver it. Where an outcome needs several ordered calls, the ordering lives in the tool, so the model chooses one thing correctly instead of sequencing six things plausibly.
Category structure
Every tool belongs to one functional category, and categories are how the surface is described to the model rather than an afterthought in the docs. At hundreds of tools across dozens of categories, discoverability is a naming problem: one canonical verb set, one noun per resource, no synonyms allowed in.
Authorisation tiering
Read, configure, consequential. The tier is declared at registration rather than checked by convention at call time, so a tool cannot ship untiered. Consequential tools stay absent from a session that has not been granted them, rather than present and refusing, because a visible tool the model cannot use is a retry loop.
Per-tenant credential isolation
Credentials are resolved per request from the caller’s own identity and never appear in the model’s context or in a tool argument. A session is bound to one tenant, so addressing another organisation is not a call the model is able to formulate rather than one it is asked not to make.
Audit trail
Each call records caller, tenant, tool, tier, redacted arguments and outcome. The record is written on the request path, so a call that fails, times out or is refused is recorded the same as one that succeeds. Reviewing what an agent did is a query, not a reconstruction from platform logs.
Vendor-neutral transport
The server implements the protocol, not a particular vendor’s client. Vendor-specific behaviour, name-length limits and schema strictness among them, is absorbed at the edge so the toolset itself stays single. Two assistant vendors consume the same registration, the same tiers and the same audit format.
Keeping the surface discoverable as it grew. At a few dozen tools, naming sorts itself out. At several hundred, every new tool competes with everything already registered, and the failure mode is silent: the model reaches for a neighbouring tool whose description also matched, calls it confidently, and returns something that reads as correct. The fix was structural rather than a better prompt. One canonical verb set, one noun per resource, category membership carried in tool metadata rather than in prose, and descriptions written to say what a tool does not do as clearly as what it does. Routing is then treated as a regression test: a held-out set of operator requests is replayed and the tool the model reaches for is checked against the tool the request meant.
What changed in the operating model
- An operator asks for an outcome and the server decides which calls that takes, instead of the model inferring an ordering from endpoint names.
- Whether an agent can perform a given operation has one answer, in the tier declaration, rather than a different answer per assistant vendor.
- A second assistant vendor was added without a second toolset, and so without a second place for governance to drift.
- Adding a tool now means placing it in a category and a tier before it can register, so the governance decision happens at authoring time rather than at review time.
- Cross-tenant reach stopped being a rule the model is asked to respect and became a call it cannot formulate.
- Reviewing what an agent did is an audit query, not an attempt to reconstruct intent from platform activity logs.
Design principles
- Task-shaped
- Scoped
- Traceable
- Governed
Continue into the evidence
More case studies
Multi-channel AI guardrails that hold
Humint Labs delivery for one accountable policy across voice, web chat and messaging, with every intervention traceable, tested and owned.
Industry: Insurance
Answering insurance enquiries, escalating everything else
Humint Labs designed and delivered a grounded service layer that resolves routine insurance enquiries, equips agents with usable evidence and escalates consequential matters with full context.
Automated regression assurance for retrieval-grounded agents
Humint Labs delivery that turns retrieval and generation evidence into a fast, repeatable release decision.