Policy
Per-bot policies, allow and deny lists, and org-level management decide which tools a bot can use.
MCP Management & Security
Govern the tools your bots can use.
Turn MCP from unmanaged plugin sprawl into a governed capability layer with policy, identity, secrets, and audit posture.
Governed MCP layer
Tools exposed only through controls
Identity
Bot-to-tool access can be tied to OAuth, OIDC, SPIFFE, and service identity patterns instead of shared credentials.
Secrets
Runtime Vault can mount approved secret leases into MCP servers through runtime environment or argument paths.
Operations
Admins can review catalogue status, assignment state, health, logs, and tool output exfiltration status from one layer.
Example posture: a bot requests a tool from the catalogue, policy checks assignment and identity, Runtime Vault mounts approved secrets, and administrators can inspect health and logs.
Capability path
MCP security becomes a routed control path.
This route now has a strong annotated panel up front, followed by a comparison block, so it reads differently from the security matrix and architecture lifecycle pages.
Governed route
Catalogue to lease
01
Catalogue
The MCP server is visible in the org catalogue before a bot can use it.
02
Assignment
An admin assigns or revokes the capability for a specific bot.
03
Policy
Allow lists, deny lists, and bot policy gates decide whether access is permitted.
04
Lease
Runtime Vault mounts approved secrets into server runtime paths without teaching the bot the value.
MCP checkpoint
Try one governed tool before scaling the catalogue.
Create a bot, assign only the MCP capability it needs, and keep the evaluation tied to policy, identity, secret mounting, and health evidence.
Sprawl vs governance
Keep MCP useful without letting plugins become invisible infrastructure.
MCP is the connection layer. Botyard is the management layer that makes those connections visible, assignable, revocable, and safer to operate across a company.
Unmanaged plugin sprawl
Useful tools, unclear ownership
- Every bot connects plugins differently.
- Credentials drift into local configuration and chat instructions.
- Teams cannot quickly answer which bot can call which tool.
- Broken servers and risky outputs are discovered after the fact.
Governed capability layer
Same tools, clear controls
- Tools are catalogued, assigned, and revocable per bot.
- Policies and identity checks sit between bots and capabilities.
- Runtime Vault supplies short-lived secrets only where approved.
- Health, logs, and output risk signals are visible to administrators.
What Botyard manages
A control plane for MCP capabilities.
Botyard keeps MCP adoption practical by separating what a tool can do from which bot is allowed to use it, under which identity, with which secret path, and with which operational visibility.
Catalogue and assignment
- Browse available MCP tools and servers from the org catalogue.
- Assign, unassign, and revoke tools per bot.
- Manage access at the bot and organization level.
- Apply policy gates and allow or deny lists before tools are exposed.
Hosted and custom MCPs
- Run hosted MCP servers through Botyard.
- Bring custom MCP servers as container images, npm packages, or external web services.
- Support BYO MCP servers without treating every plugin as a permanent bot capability.
- Monitor server health and logs so broken integrations are visible.
Secrets and identity
- Mount Runtime Vault leases into approved MCP server runtime paths.
- Use OAuth and OIDC bot-to-tool identity where integrations support it.
- Support SPIFFE and service identity patterns for workload-oriented access.
- Avoid storing long-lived secrets in prompts, memory, or bot configuration.
Mid-page action
Keep secrets at the platform boundary.
Runtime Vault lets the bot use an approved credential path without turning the credential into prompt or configuration sprawl.
Runtime path
Secrets and identity stay attached to the platform boundary.
MCP servers often need credentials. Botyard can keep those credentials out of bot prompts and long-lived configuration by mounting approved Runtime Vault leases only when an assigned server needs them.
Catalogue
The MCP server is visible in the org catalogue.
Assignment
An admin assigns or revokes the capability for a specific bot.
Policy
Allow lists, deny lists, and bot policy gates decide whether access is permitted.
Identity
OAuth, OIDC, SPIFFE, or service identity ties the call to a bot workload where supported.
Runtime Vault
Approved leases mount into server runtime paths without teaching the bot the secret.
Health
Logs, health state, and output risk signals help admins operate the integration.
Current boundaries
Clear claims, no magic security blanket.
Botyard governs MCP access paths, but this page avoids claiming complete approval workflows, complete tool-call audit coverage, or scanning of local bot state.
- MCP and tool-call audit produces reviewable evidence as part of the governance layer.
- Provider and model spend policies are scoped through enterprise onboarding.
- Responsibility, local bot state, and file exfiltration scanning are scoped per integration.
Govern MCP in Botyard
Give bots tools without giving up control.
Start with a catalogue, assign only the capabilities each bot needs, and keep policy, identity, secrets, health, and audit posture in one governed layer.