What can you do with this server?

AnB-MCP is a security-focused server that lets AI agents use secrets without ever seeing the plaintext values, acting as a secure bridge between agents and a Key Management System (KMS). * anb_list: Retrieve the names and metadata (description, key epoch, length, entropy bits) of all secrets the identity is authorized to reference — never the actual values. * anb_exec: Run operator-allowlisted commands with secrets automatically injected into the child process's environment via placeholders. Only commands matching allowlisted rules are permitted. Returns exit code and redacted stdout/stderr — the raw secret never reaches the caller. * anb_redact: Scrub arbitrary text by replacing known secret values and high-entropy tokens with placeholders — useful before logging or returning output that might inadvertently contain a secret. * anb_render_to_file: Resolve a template containing placeholders and write the result as a mode-0600 file to a restricted directory. Returns only the file path — the resolved content is never returned to the caller. * anb_status: Perform a health and authorization self-check reporting Bob (KMS) reachability, lock status, enrolled identity, authorized key prefixes, and exec-rule count — without exposing any secret values.

AnB-MCP

by kaka-milan-22

Overview Schema Source Related Servers Discussions Admin

Local

AnB-MCP

An MCP server front-end for AnB that lets AI agents use secrets without ever seeing them.

anb-mcp quickstart

Headline guarantee: even a fully prompt-injected agent, calling every tool in every way, cannot extract a raw key. No tool returns a plaintext secret; reveal paths require a TTY that this server does not have, so alice refuses them.

Unlike a naive "secrets MCP" that hands the key to the model, here the agent gets placeholders and outcomes — the plaintext stays behind the anb-mcp → alice → Bob boundary.

How it works

Agent (untrusted) ──MCP/stdio──► anb-mcp ──exec──► alice ──mTLS──► Bob ──► master key
                                  (this repo)      (AnB client)   (AnB KMS daemon)

anb-mcp runs as a dedicated, narrowly-scoped AnB identity (not your operator CLI identity), so a compromised agent's blast radius is limited to what Bob authorizes for that identity.

Related MCP server: AgentVault MCP Server

Tools

Tool	Does	Returns
`anb_list`	List secret keys this identity may reference	names + metadata, no values
`anb_exec`	Run an operator-allowlisted command with secrets injected into the child's env	exit code + redacted stdout/stderr
`anb_status`	Health / authz self-check	Bob reachability, identity, authorized prefixes, rule count
`anb_redact`	Scrub text — secret values + high-entropy tokens → `<agent-vault:key>`	redacted text
`anb_render_to_file`	Render a placeholder template, write a 0600 file under the render dir	the path, never the content

Never exposed: any reveal / get-plaintext / shell tool.

Prerequisites

This is a thin front-end; it depends on AnB. For v0.1 you need:

A working alice + bob (AnB) on the host.
A dedicated MCP identity enrolled with Bob, scoped to only the key prefixes the agent should use. Point the server at it via ANB_MCP_ALICE_DIR (default ~/.anb/alice-mcp). Do not reuse your operator identity.
Exec allowlist with scope tags — alice's exec rules carry a 4th scope column; only rules tagged mcp apply to this surface (default-deny). Tag a rule for the agent by appending mcp (e.g. ^/opt/.../curl ...$\tOPENAI_KEY\t# call\tmcp). (Requires AnB with alice exec --surface, alice redact, and alice status --json — all shipped.)

Build

go mod tidy
go build -o anb-mcp .

Register with Claude Code

claude mcp add -s user -e ANB_MCP_ALICE_DIR=$HOME/.anb/alice-mcp \
  anb -- /path/to/anb-mcp

Or in ~/.claude.json under mcpServers:

{
  "mcpServers": {
    "anb": {
      "command": "/path/to/anb-mcp",
      "env": { "ANB_MCP_ALICE_DIR": "/Users/you/.anb/alice-mcp" }
    }
  }
}

Tools surface as mcp__anb__anb_list, mcp__anb__anb_exec, mcp__anb__anb_status.

Status

v0.1 — done, verified end-to-end (and by a real agent). All three tools work against a live Bob: anb_status returns real KMS state; anb_exec runs allowlisted commands and denies the rest; and a secret injected via --env <agent-vault:key> is used by the child process while the caller receives only the redacted placeholder — the plaintext never reaches the agent. Confirmed both by go-sdk-client invariant tests (test/) and by an independent Claude Code session calling the tools over MCP. See CHANGELOG.md.

Roadmap: see PLAN.md. (v0.2 adds anb_render_to_file + a dedicated anb_redact tool; v0.3 lowers per-call latency and adds per-agent ephemeral, short-TTL scoped credentials — while keeping alice as a separate process, so the no-reveal guarantee stays structural, not a code-discipline promise.)

License

MIT

Available Tools

5 tools

anb_execA

Run an operator-allowlisted command with named secrets injected into the child process's environment. SIDE EFFECT: spawns a real subprocess — default-deny, only commands matching a scope=mcp allowlist rule run, everything else is refused. NOT idempotent (effects depend on the command). Requires an enrolled identity and a reachable, unlocked Bob to resolve agent-vault:key placeholders. Returns the exit code plus REDACTED stdout/stderr; the raw secret is never returned even if the child prints it. A denied or failed command returns a non-zero exit_code with the reason in stderr_redacted.

ParametersJSON Schema

Name	Required	Description
`env`	No	child env entries, each in KEY=VALUE form; VALUE may contain <agent-vault:key> placeholders that Bob resolves into the child env only — never echoed back. Omit for none
`args`	No	positional arguments passed to the command in order, each literally (no shell parsing/globbing); omit for none
`command`	Yes	absolute path of the executable to run (e.g. /usr/bin/curl); the full command line must match a scope=mcp allowlist rule or it is refused

Output Schema

ParametersJSON Schema

Name	Required	Description
`exit_code`	Yes
`stderr_redacted`	Yes	command stderr with secrets redacted (includes an allowlist-denial message when the command was not permitted)
`stdout_redacted`	Yes	command stdout with secrets redacted

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It thoroughly discloses side effects: 'spawns a real subprocess', 'default-deny', 'NOT idempotent (effects depend on the command)', requires Bob, 'Returns the exit code plus REDACTED stdout/stderr', and 'the raw secret is never returned even if the child prints it'. It also covers failure modes (denied or failed command returns non-zero exit_code with reason).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose and key constraints. It could be slightly more concise, but every sentence adds meaningful information. The length is justified given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (execution with secrets, allowlist, prerequisites), the description is complete. It covers behavior, side effects, prerequisites, return values, and failure modes. An output schema exists, but the description still explains redaction and return structure adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (all three parameters have schema descriptions). The description adds value by explaining the KEY=VALUE form for env, placeholder resolution via Bob, no shell parsing for args, and absolute path requirement for command. This goes beyond the schema's formal definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Run an operator-allowlisted command with named secrets injected into the child process's environment.' It uses a specific verb ('run') and resource ('operator-allowlisted command'), and distinguishes itself from sibling tools like anb_list (listing) and anb_redact (redacting) by being the execution tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: 'default-deny, only commands matching a scope=mcp allowlist rule run', 'NOT idempotent', 'Requires an enrolled identity and a reachable, unlocked Bob'. It tells when to use (allowlisted commands) and when not to use (if command not allowlisted or prerequisites not met).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

anb_listA

List the secret key names and metadata this identity may reference — never the values. Read-only and idempotent, no side effects. Requires an enrolled identity and a reachable, unlocked Bob KMS daemon; errors if Bob is unreachable/locked or the identity is unauthorized. Use this to discover which agent-vault:key names exist before referencing them in anb_exec or anb_render_to_file.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`keys`	Yes	secret key names and metadata this identity may reference; never values

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description fully discloses behavioral traits: read-only and idempotent, no side effects; requires enrolled identity and reachable, unlocked Bob KMS daemon; errors on unreachable/locked or unauthorized identity. This compensates for the lack of annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading key information (purpose, constraints, usage hint), with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool (0 params, output schema present), the description covers purpose, constraints, prerequisites, error conditions, and usage hints comprehensively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters and 100% schema coverage, the baseline is 4. The description does not need to add parameter info, and it does not add any beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists secret key names and metadata, never values, making the purpose specific and differentiating it from sibling tools like anb_exec and anb_render_to_file.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: use to discover key names before referencing them in anb_exec or anb_render_to_file, but does not explicitly state when not to use or list alternative tools for other scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

anb_redactA

Scrub text: replace known secret values and high-entropy tokens with agent-vault:key placeholders. Read-only, idempotent, no side effects, and needs no Bob connection. Fail-safe by design — may over-redact, never under-redact. Use before logging or returning any text that might contain a secret.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	text to scrub; known secret values and high-entropy tokens become <agent-vault:key> placeholders

Output Schema

ParametersJSON Schema

Name	Required	Description
`redacted`	Yes	the input with secrets replaced by placeholders

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses: read-only, idempotent, no side effects, no external dependencies, and the over-redact guarantee. This provides high transparency for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: core function, behavioral traits, usage guidance. No fluff, front-loaded, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and an output schema (implied), the description covers purpose, safety, usage context, and behavioral guarantees. No gaps given the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter 'text' with 100% schema description coverage. The description repeats the same information as the schema ('known secret values and high-entropy tokens become <agent-vault:key> placeholders'), adding no new semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Scrub text') and resource ('text'), with clear output format ('<agent-vault:key> placeholders'). It is distinct from siblings which involve execution, listing, rendering, or status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises 'Use before logging or returning any text that might contain a secret.' It also notes 'needs no Bob connection' and fail-safe behavior. While it doesn't explicitly list when not to use, the guidance is clear and helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

anb_render_to_fileA

Render a template containing agent-vault:key placeholders and write the resolved file (mode 0600) under the confined render dir. SIDE EFFECT: writes a file to disk (overwrites if the path exists). Requires an enrolled identity and a reachable, unlocked Bob to resolve placeholders. Returns the written path, NEVER the resolved content — the caller never sees the secret values. out_path is relative to the render dir; absolute paths and .. traversal are rejected.

ParametersJSON Schema

Name	Required	Description	Default
`out_path`	Yes	destination path RELATIVE to the render dir (e.g. "app/.env" or "config/db.conf"); absolute paths and .. traversal are rejected. Parent dirs are created as needed
`template`	Yes	file content with <agent-vault:key> placeholders; resolved values are written to disk (mode 0600), never returned to the caller

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	Yes	the absolute path the rendered file was written to
`written`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully discloses behaviors: writes to disk (mode 0600, overwrites), requires identity and Bob, never returns content, and rejects absolute paths/.. traversal. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences efficiently convey purpose, side effects, prerequisites, and constraints. Front-loaded with action and key details, no superfluous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (not shown but indicated as true), the description covers all necessary aspects: purpose, side effects, prerequisites, input constraints, and behavior. No gaps identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds value: clarifies out_path as relative to render dir with security constraints, and explains template placeholders. This is beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool renders a template with placeholders and writes to a file, with details on security and output. It explicitly contrasts with siblings by mentioning template rendering and file writing, distinguishing it from anb_exec, anb_list, anb_redact, and anb_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use (render and write secrets to a file), mentions side effects (writes file, overwrites), and prerequisites (enrolled identity, unlocked Bob). It does not explicitly state when not to use or provide alternatives, but the sibling list implies context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

anb_statusA

Read-only self-check: reports enrollment, client-cert presence, Bob reachability and unlock state, identity, server name, and idle-TTL. No side effects, idempotent, returns NO secret values. Call this first to confirm the vault is ready before anb_list/anb_exec/anb_render_to_file; on failure the error field explains why (e.g. Bob unreachable or locked).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`bob_addr`	No
`enrolled`	Yes
`identity`	No
`client_cert`	Yes
`server_name`	No
`bob_unlocked`	Yes
`bob_reachable`	Yes
`idle_ttl_seconds`	No

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description fully carries the burden. It discloses it is read-only, idempotent, returns no secret values, and has no side effects. This provides complete behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences, each adding essential information. It is front-loaded with the key purpose. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no inputs and an output schema, the description is complete: it covers behavior, error handling, usage context, and safety. The output schema exists, so return values are not needed in the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the baseline is 4 per the zero-params rule. The description adds meaning by explaining what the tool does and what it returns, which is beyond the empty input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Read-only self-check' which clearly specifies the verb and resource. It lists specific reports such as enrollment, client-cert presence, Bob reachability, etc. It also distinguishes this tool from siblings by stating it should be called first before anb_list, anb_exec, and anb_render_to_file.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use: 'Call this first to confirm the vault is ready before...' and implies when not to use by mentioning alternatives. It also explains that on failure, the error field explains why, guiding the agent on next steps.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv0.2.1Jun 27, 2026

Changedanb_exec3 fields changed

changedInput schema / properties / args / description

Previous value: -"command arguments"New value: +"positional arguments passed to the command in order, each literally (no shell parsing/globbing); omit for none"

changedInput schema / properties / command / description

Previous value: -"absolute path of the command to run; must match an allowlisted rule scoped to mcp"New value: +"absolute path of the executable to run (e.g. /usr/bin/curl); the full command line must match a scope=mcp allowlist rule or it is refused"

changedInput schema / properties / env / description

Previous value: -"child env entries, each in KEY=VALUE form; the VALUE may contain <agent-vault:key> placeholders that are resolved without ever returning the secret"New value: +"child env entries, each in KEY=VALUE form; VALUE may contain <agent-vault:key> placeholders that Bob resolves into the child env only — never echoed back. Omit for none"

Changedanb_render_to_file1 field changed

changedInput schema / properties / out_path / description

Previous value: -"destination path RELATIVE to the render dir; absolute paths and path traversal are rejected"New value: +"destination path RELATIVE to the render dir (e.g. \"app/.env\" or \"config/db.conf\"); absolute paths and .. traversal are rejected. Parent dirs are created as needed"

5 tool updatesv0.1.0Jun 27, 2026
- First observedanb_exec
- First observedanb_list
- First observedanb_redact
- First observedanb_render_to_file
- First observedanb_status

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.7/5.0

Scored 2026-06-27 11:55 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: executing commands with secret injection, listing secret keys, redacting secrets from text, rendering templates to disk, and checking server status. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent 'anb_<verb>' pattern, with verbs like exec, list, redact, render_to_file, and status. This makes the tool set predictable and easy to navigate.

Tool Count5/5

With exactly 5 tools, the server is well-scoped for its purpose—providing secure vault-integrated operations without unnecessary complexity. The count feels appropriate for the domain.

Completeness5/5

The tools cover the full lifecycle needed for a secret-aware MCP server: status checking, secret listing, command execution, template rendering, and output redaction. While there is no tool for managing secrets themselves, that is intentional for a client-side tool, and the set is complete for its intended use.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

MANDATE Credential Broker B
io.github.projetnanocorp
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Security
111
Tap
io.github.LeonTing1010
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
Browser Automation Web Scraping
217
OneDroid SynapseOAuth
ai.onedroid
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
Security Observability
1
Occludra — MCP Gateway (AI Security Gateway)
ai.occludra
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
Security Agent Orchestration
1

Related MCP Servers

heddle
Developer Tools Security
goweft
A
license
Not graded
quality
A
maintenance
Enables users to define and run MCP tools using declarative YAML configs with built-in trust enforcement, credential brokering, and tamper-evident audit logging.
Updated 14 days ago (2026-09-06 01:54 UTC)
14
MIT
AgentVault MCP Server
Security Autonomous Agents
PabloTheThinker
A
license
B
quality
D
maintenance
Enables AI agents to manage secrets and credentials from a secure vault via MCP tools over stdio.
Updated 3 months ago (2026-06-19 16:49 UTC)
7
MIT
codex-mcp-longrun
Shell Access Command Line
woffko
F
license
A
quality
B
maintenance
A local STDIO MCP server for running one bounded command and waiting for its final result, eliminating model-driven polling. Designed for builds, test suites, and other trusted foreground commands.
Updated 8 days ago (2026-09-12 16:01 UTC)
3
2
-
scriptit
Agent Orchestration Autonomous Agents App Automation
shreyjindal81
F
license
Not graded
quality
C
maintenance
Enables agents to connect to remote MCP servers once, access their tools through a compact MCP endpoint, pair a CLI inside sandboxes, and create watches that turn command or tool output into pollable structured events.
Updated 24 days ago (2026-08-27 07:33 UTC)
2
-