Veil is an MCP server that lets an AI agent orchestrate secure credential storage while keeping secret values invisible to the model, with a human approving and entering credentials through a separate trusted UI.
secret.store — Request that a human provide and store a credential to a chosen destination (Google Secret Manager, .env file, or Firestore); only non-sensitive metadata is passed to or returned from the agent.
secret.status — Poll a pending credential request for its non-sensitive status; optionally block up to 60 seconds for a terminal state.
secret.cancel — Cancel a pending request and destroy any credential value already entered by the human.
secret.revise — Cancel a pending request and create a corrected one; invalidates the prior authorization so the human must re-authorize from scratch.
secret.destinations — List the available destination adapters and the exact target fields each expects.
Enforces human authorization via a loopback UI, with risk classification and optional second confirmation for high/medium-risk writes.
Supports Google Secret Manager, path-restricted .env files, and Firestore, while refusing arbitrary-network destinations.
Guarantees structurally that tool arguments/results cannot carry secret values, and screens for credential-shaped input.
Integrates with Google Cloud Secret Manager and Firestore to securely store credentials. Supports creating, updating, and replacing secrets in Secret Manager, and storing secrets in Firestore (with warnings about high-risk operations).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Veil store my Stripe production API key in Google Secret Manager"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An AI agent can orchestrate the placement of a credential without ever receiving the credential value, while a trusted human-controlled interface independently authorizes where that credential is allowed to go.
That sentence is the entire promise. Veil is an MCP server plus a secure input broker: the agent says "put a Stripe production key in Google Secret Manager", the human sees exactly which project and secret will be written and types the value into Veil's own window, and the value goes straight to the destination. The model never holds it.
Implemented from SPEC.md.
Veil is a stdio MCP server, so you do not run it yourself — your MCP client starts it, the same way it starts any other npm-published server. Requires Node 20+.
cd ~/some/project
claude mcp add veil -e VEIL_ENV_ALLOWED_ROOTS="$PWD" -- npx -y veil-mcp serveAdd -s project to record it in the repository's .mcp.json instead of your own config.
Drop this into the client's MCP configuration — the mcpServers block is the same shape
everywhere:
{
"mcpServers": {
"veil": {
"command": "npx",
"args": ["-y", "veil-mcp", "serve"],
"env": {
"VEIL_ENV_ALLOWED_ROOTS": "/absolute/path/to/your/project"
}
}
}
}Prefer a pinned install to an ephemeral one:
npm install -g veil-mcp
# then use `veil-mcp serve` as the command, with no npxSet VEIL_ENV_ALLOWED_ROOTS. The .env adapter refuses to write outside those
directories, and it defaults only to the server's working directory. Everything else is
optional — see Configuration.
Google Secret Manager and Firestore need application default credentials
(gcloud auth application-default login) and the optional google-auth-library package,
which npm installs by default. Veil reports ADAPTER_UNAVAILABLE when either is missing.
Ask your agent for something like "store my Stripe test key in .env". What happens:
The agent calls secret_store describing where the credential goes. It sends no
value, because the tool has no field that could carry one.
Veil opens its own window on your machine showing the credential name, destination, project, environment, operation and risk. The agent does not receive that link.
You type the value into a masked field. Medium- and high-risk operations ask for a second confirmation, after entry and before the write.
Veil writes it and tells the agent STORED plus a destination reference — never the
value.
Veil's own stderr carries structured audit JSON. Nothing else is expected of you in the terminal.
Related MCP server: Janee
It removes an entire class of failures caused by the agent knowing the secret. With Veil in the loop, a credential does not pass through:
LLM prompts or conversation history
MCP tool arguments or tool results
agent memory or generated code
shell command arguments or process argv
logs, debug traces or telemetry
URLs
model-visible command output
Veil does not make an AI agent trustworthy, and it is not "safe AI". It does not guarantee that the agent picked the right destination, that it understood you, that it is free of prompt injection, that the destination is itself secure, that your machine is uncompromised, or that a credential cannot be misused later by software that legitimately receives it.
There are two separate problems here:
Question | Veil's answer |
Should the agent know the secret? | No. |
Should the agent decide alone where the secret goes? | Not without human authorization. |
Veil answers those two. It does not claim to answer the rest.
Trusted with the credential value:
The human at the keyboard
Veil's secure input UI (loopback only, in your control)
Veil's secure input broker (this process)
The selected destination adapter
The destination provider (e.g. Google Secret Manager)
NOT trusted with the credential value:
The LLM
The agent / MCP client
The conversation
The prompt and any repository content it read
Generated code
Logs, telemetry, crash reportsVeil's runtime dependency list is one package (zod, for input validation) plus an
optional google-auth-library used only when a cloud destination is selected. The MCP
protocol is implemented in-tree rather than through the official SDK, which would add ~90
packages — including HTTP servers and an OAuth stack — to a process that holds plaintext
credentials.
This diagram does not claim the trusted components are invulnerable. It says where the credential is allowed to exist. Veil is security-sensitive software: if Veil itself is malicious or compromised, the boundary is gone. Its source, dependencies and releases deserve the scrutiny you would give any credential-handling tool.
The secret flow — the human's path, which the model cannot observe:
Human ─▶ Veil secure UI (127.0.0.1) ─▶ Broker ─▶ Adapter ─▶ DestinationThe agent flow — everything the model sees:
LLM ─▶ MCP client ─▶ Veil MCP server ─▶ non-sensitive result metadataThe MCP tool schema has no property capable of carrying a credential. That is structural,
not a prompt instruction: there is no value, secret_value, password, token,
content or raw_secret field to abuse, closed schemas reject unknown properties, and
arguments are screened for credential-shaped values before they are parsed.
{
"destination": "gcp-secret-manager",
"name": "STRIPE_SECRET_KEY",
"target": { "project": "my-production-project", "secret": "STRIPE_SECRET_KEY" },
"write_mode": "new-version",
"environment": "production",
"description": "Stripe production API key"
}Veil replies with a request_id, a risk classification and the normalized destination —
and opens its own authorization window on your machine. The agent polls secret_status.
The agent does not get the authorization link. That link is a capability: anything
holding it can complete the human's half of the flow, and an agent with a shell or an HTTP
tool is precisely the threat model. Veil hands it to your browser and prints it to its own
console instead. Set VEIL_DISCLOSE_AUTHORIZATION_URL=true if your setup needs the agent
to relay the link (for example, a remote or headless session) — and understand that this
lets a compromised agent authorize its own request.
Tool | Purpose |
| Create a credential request. Returns non-sensitive metadata and a request id. |
| Poll a request. Never returns credential material. |
| Cancel a pending request; any entered value is destroyed. |
| Invalidate an authorization and start a new one. Nothing is edited in place. |
| List destinations and the target fields each expects. |
Stage A shows the credential name, destination provider, project/account, resource, operation and risk before the value is entered. High-risk operations (production overwrite, plaintext storage, application databases, replacing a credential) require a second confirmation in Stage B, after entry and before the write. The value is never displayed back.
The page the human reads and the operation the executor performs are the same immutable object — there is no separate "display destination". Any change to destination, project, secret name, operation, write mode or adapter invalidates the authorization and requires a new one.
Adapter | Class | Notes |
|
| Preferred. |
|
| Path-restricted, symlink-refusing, atomic |
|
| Always warns; always requires Stage B. |
arbitrary-network destinations (generic HTTP POST, webhooks) are not implemented, and
the adapter registry refuses to register one.
Stated plainly, because a security tool that oversells itself is worse than none:
The broker process sees the secret. That is the point: something must, or storage is impossible. The guarantee is that only the minimal trusted transport and destination components do.
Memory erasure is best-effort. SecretBuffer wipes the exact Buffer it owns, and
the HTTP body is percent-decoded into buffers Veil wipes too. But any conversion to a
JavaScript string — which writing a .env line requires — creates an immutable copy that
V8 may keep until garbage collection, and that copy cannot be wiped. Veil minimizes those
conversions rather than pretending they do not happen.
The UI is loopback HTTP. Any process running as your user on your machine can reach it, and any such process could also imitate it. Each Veil process prints a random identity phrase that its pages display (anti-spoofing aid, not a cryptographic control). Withholding the link from the agent raises the bar; it does not stop a process that can read Veil's console output, list the browser's argv, or scan loopback ports.
Veil does not audit the destination. If you authorize a credential into a Firestore document, Veil writes it there and tells you it is a bad idea; it does not stop you.
Timeouts are provider-level. Veil cannot cancel a blocking SDK call from outside it, so each adapter passes an explicit timeout to the provider. A destination SDK that ignores its own timeout can still hold a request — and its secret — open.
Preflight is best-effort. A provider that is unreachable at preflight is reported as unavailable rather than guessed at.
Crash semantics. A crash between the provider write and the response can leave a credential written with no local record of success. Veil reports the request as failed; the destination is the source of truth.
git clone https://github.com/rosostolato/veil-mcp && cd veil-mcp
npm install
npm run check # typecheck + lint + format + tests
npm run buildTo point a client at your checkout, use node /path/to/veil-mcp/dist/index.js as the
command instead of npx.
Configuration is read from Veil's own environment — never from tool arguments, so an agent cannot relax a policy:
Variable | Default | Meaning |
|
| Request expiry. |
|
| Upper bound on one destination write. |
|
| Require confirmation for medium-risk operations. |
|
| Secure UI bind address. |
|
| Open the authorization window automatically. |
|
| Return the authorization link to the agent. |
| current directory | Roots the |
|
| Permit writing into a git-tracked env file. |
| all | Comma-separated allowlist. |
npm test # everything
npm run test:security # the adversarial suite only
npm run check # what CI runsThe security suite is a product requirement, not a nicety. It contains canary-leakage
detection across every observable channel, malicious-agent tests, prompt-injection
fixtures, TOCTOU and replay tests, 100-way concurrency stress, race conditions, crash
paths (including a real SIGKILL mid-write), provider-failure simulation, UI checks and
fuzzing. A release is blocked if any canary leaks, any authorization bypass succeeds, any
post-approval mutation succeeds, any completed request is replayable, any secret crosses a
request boundary, any raw provider error reaches MCP, or any high-risk operation skips
confirmation.
See docs/SECURITY_MODEL.md for the invariant-to-test map.
Version 0.1.0, built to SPEC.md, which stays in the repository as the
authoritative description of the intended behaviour. The implementation is TypeScript on
Node; it was ported from an equivalent Python implementation, which remains in the git
history. Every substantial module and test
cites the section it implements, so a reviewer can check the code against the requirement
rather than against a summary of it.
The MVP is complete and the full suite — including the adversarial one — passes. What remains before anyone should rely on it in anger: independent review, human-factor testing of the confirmation UI (SPEC.md §35), and signed release artefacts (§43).
Security is the product here, so the bar for changes is specific rather than bureaucratic:
A change that touches credential handling, authorization or the MCP surface needs a test that attempts to break the invariant it affects, not only one that shows it working.
Never weaken a security test to make a suite pass. If a test reveals an architectural flaw, the architecture is what changes.
New runtime dependencies in the core are opposed by default. The broker is the trusted computing base for credential material; provider SDKs belong behind an optional extra.
Run npm run check before opening a pull request.
Found a vulnerability? Please report it privately through GitHub's security advisories rather than opening a public issue.
Apache License 2.0 © 2026 Eduardo Rosostolato.
Cancel a pending request. Any credential already entered is destroyed.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly discloses a critical side effect: 'Any credential already entered is destroyed.' This is valuable transparency for a destructive mutation. However, it doesn't mention other effects like whether cancellation is reversible or requires special permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, highly concise, and front-loaded with the core action ('Cancel a pending request') followed by a key consequence. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description doesn't explain return values or error conditions. While it covers the key destructive behavior, it lacks guidance on when to use the reason parameter, potential side effects beyond credential destruction, and any prerequisites. For a security-related tool, more context would be helpful, but the essential purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain the parameters at all. It doesn't mention that request_id is required or that reason is optional. The schema itself provides clear names, but the description adds no additional meaning, leaving the agent to infer that request_id identifies the request and reason is for audit context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cancel a pending request' which is a specific verb (cancel) and resource (request). It distinguishes from siblings like secret.store and secret.revise, as it focuses on cancellation and the destruction of already-entered credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for pending requests ('Cancel a pending request') but gives no explicit guidance on when to use it versus alternatives, nor exclusions. It lacks context like 'use secret.revise to modify instead' or 'do not use for completed requests'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the destinations this Veil instance can write to, with the target fields each one expects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint: true, and the description does not contradict it. It adds context about the content (target fields) which is useful for the agent. Given the annotation already covers safety, the description provides adequate extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and resource, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description fully explains what it does and includes the key detail about target fields, which is likely sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameterswing schema coverage is 100% (vacuously). Baseline for 0 params is 4, and the description clarifies that the output includes target fields per destination, which adds contextual meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and the specific resource (destinations this Veil instance can write to), and adds the detail about target fields. It distinguishes itself from sibling tools like store, cancel, revise, which involve mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to discover available destinations and their required fields), but does not explicitly contrast with alternatives. Since it's a simple listing tool, the purpose clarity implicitly covers usage, though no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a pending request and create a new one. The original authorization is invalidated and the human must authorize the new operation from scratch; an authorized operation can never be edited in place.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Logical name of the credential, e.g. STRIPE_SECRET_KEY. This is a label, never the credential value. | |
| target | Yes | Where the credential goes. Fields depend on the destination; call secret.destinations for the exact contract. | |
| request_id | Yes | ||
| write_mode | No | create | |
| description | No | Short human-readable purpose, shown to the user. | |
| destination | Yes | Which destination adapter should receive the credential. | |
| environment | No | Environment you believe this destination belongs to. Advisory only: Veil classifies the destination itself and uses the stricter of the two. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses that the original authorization is invalidated, the human must reauthorize from scratch, and authorized operations cannot be edited in place. This covers the key side effects and workflow consequences of a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the core action, and the second provides the key behavioral consequence and an important invariant. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with nested objects and no output schema, the description explains the compound nature and authorization consequences sufficiently. It could additionally mention that all parameters must be resubmitted for the new request, but the schema and existing wording make the required inputs inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, so most parameters have descriptions already. The tool description adds context around request_id by referring to 'pending request' and 'new operation from scratch,' but it does not explain parameter interactions or destination-specific requirements beyond what the schema provides. This is adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a compound operation: 'Cancel a pending request and create a new one.' The title, 'Replace a credential request with a corrected one,' further specifies the resource and intent, distinguishing this from sibling tools like secret.cancel and secret.store.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use the tool: when a pending request must be corrected, and specifically notes that 'an authorized operation can never be edited in place.' It doesn't explicitly contrast with secret.cancel or secret.store, but the described workflow makes the intended use case unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the non-sensitive status of a credential request. Never returns credential material.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| wait_seconds | No | Optionally block until the request reaches a terminal state or this many seconds elapse. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the readOnlyHint annotation by guaranteeing that no credential material is ever returned. This safety guarantee is a key trait not covered by annotations, though it does not disclose blocking behavior or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core purpose and add a critical safety note. There is no unnecessary detail or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and a read-only annotation, but the description omits key behavioral details such as the optional blocking behavior via wait_seconds and what the response actually contains (e.g., status list, error scenarios). Without an output schema, the description should describe the return value format more fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation of the parameters. request_id is self-explanatory from its name, but wait_seconds is already described in the schema. With only 50% schema description coverage, the description fails to compensate for the missing request_id semantics or clarify how to obtain such an ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the status of a credential request and explicitly mentions it never returns credential material. This distinguishes it from siblings like secret.cancel or secret.store, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking status but provides no explicit guidance on when to use it versus alternatives. There is no mention of 'use when you need to check status' or exclusions like 'do not use to cancel requests'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask the human to provide a credential and have Veil write it to the destination described here. The credential value is never passed through this tool, never returned by it, and never becomes visible to the model: the user enters it in Veil's own trusted window. Share the returned authorization_url with the user, then poll secret.status.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Logical name of the credential, e.g. STRIPE_SECRET_KEY. This is a label, never the credential value. | |
| target | Yes | Where the credential goes. Fields depend on the destination; call secret.destinations for the exact contract. | |
| write_mode | No | create | |
| description | No | Short human-readable purpose, shown to the user. | |
| destination | Yes | Which destination adapter should receive the credential. | |
| environment | No | Environment you believe this destination belongs to. Advisory only: Veil classifies the destination itself and uses the stricter of the two. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses that the credential value never passes through the tool, is never returned, and never becomes visible to the model—a key behavioral trait. It also outlines the multi-step process involving an authorization_url and polling. Annotations already signal destructive and open-world behavior, and the description complements these without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and includes essential security and workflow context. Every sentence earns its place, and there is no redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested target, multiple destinations, write modes, environment), the description covers the critical workflow and security aspects, and points to secret.destinations for detailed contracts. It does not explain write_mode or environment semantics, but those are well-documented in the schema. Overall, it is reasonably complete for a tool of this intricacy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not directly elaborate on any input parameters, but the schema provides extensive descriptions for 83% of fields. It directs users to secret.destinations for the target contract, which covers the remaining nuance. Since the schema already carries the semantic load, the description adds little beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: asking the human for a credential and having Veil write it to a specified destination. It distinguishes itself from siblings like secret.status and secret.cancel by focusing on the store action and includes critical security context (credential not visible to model) and subsequent steps (share authorization_url, poll status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow guidance: ask the user, share the authorization_url, and poll secret.status. It implies this tool is for new credentials but does not explicitly contrast with secret.revise or specify when not to use it. The flow is described well, but alternative exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0secret.cancelsecret.destinationssecret.revisesecret.statussecret.storeScored across 5 tools
Each tool has a clearly distinct role: status checks a pending request, store initiates a credential request, cancel aborts it, revise replaces it, and destinations lists available targets. No overlap in purpose, making agent selection unambiguous.
All tool names follow a consistent 'secret.<action>' pattern with clear, concise verbs (status, store, cancel, revise) and one noun (destinations). The pattern is uniform and predictable, though 'destinations' is a noun rather than a verb, it still fits the domain prefix style.
With 5 tools, the server is tightly scoped to credential request management. This is within the ideal range and each tool earns its place; no redundancy or bloat.
The tool surface covers the entire lifecycle of a credential request: create (store), read (status), update/replace (revise), delete (cancel), and context (destinations). There are no evident gaps—even revision gracefully handles invalidation of prior authorizations.
Hosted MCP server for AI agent identity, permissions, verification, and reusable proof.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Credential isolation for AI agents: placeholder secrets, policy checks, optional human approval.
