AgentKey is a security and authorization layer for AI agents. It sits between AI agents and the systems they touch, enforcing fail-closed permissions, preventing unauthorized actions with single-use execution tokens, managing human approvals, and generating cryptographically signed, offline-verifiable audit evidence. It is built for AI agents and MCP workflows.

How does AgentKey prevent unauthorized AI agent actions?

In enforce mode, every tool call routed through AgentKey is checked against defined permissions before it runs, and an approved action can be bound to a single-use execution attempt that expires after use. An action that is not explicitly allowed is denied by default. In the default observe mode the same checks run and are recorded, with would-block markers, without blocking. Protection applies to calls routed through the SDK or the MCP bridge.

What is fail-closed permission for AI agents?

Fail-closed permission means that if AgentKey cannot verify an action is allowed, the action is blocked by default. This is the opposite of fail-open systems where unclear permissions allow actions through. Fail-closed is the safer approach for AI agents that may attempt unexpected or harmful actions.

How does AgentKey protect against prompt injection?

AgentKey scans untrusted content before it reaches the model and validates every tool call routed through it against an explicit permission policy. In enforce mode, a call blocked by policy or by a quarantined input scan does not run; in the default observe mode the same call is recorded with a would-block marker instead of being blocked. This covers tool calls routed through the AgentKey SDK or MCP bridge; it does not intercept calls made outside the integration.

What is MCP security in AgentKey?

MCP security in AgentKey refers to protecting Model Context Protocol servers and the AI agents that connect to them. AgentKey adds a security layer that controls what MCP tools an agent can call, validates inputs, requires human approval for sensitive operations, and records every action as verifiable evidence.

What are cryptographically signed audit logs?

AgentKey generates audit evidence that is cryptographically signed, meaning it cannot be tampered with after creation. Each audit record includes a digital signature that proves its authenticity. This evidence can be verified offline, without access to AgentKey's servers, making it suitable for compliance, incident response, and legal proceedings.

Does AgentKey support human-in-the-loop approval?

Yes. AgentKey supports human-in-the-loop approval workflows where sensitive actions require manual sign-off before execution. You can define which actions need human approval, and AgentKey will pause the agent, notify the approver, and only execute the action after explicit approval.

How much does AgentKey cost?

AgentKey offers a free tier for getting started. Paid plans scale based on agent usage and the number of protected actions. Visit the pricing page for current plan details and feature comparisons.

Which AI platforms does AgentKey work with?

AgentKey is agent-agnostic. Any agent whose tool calls can be wrapped with the JavaScript or Python SDK, or whose MCP client can be pointed at the AgentKey MCP bridge, works with it. The agent's framework or model does not matter: AgentKey sits on the tool-call path, not inside the model.

Can AgentKey audit evidence be used for compliance?

Yes. AgentKey's audit evidence is cryptographically signed, offline-verifiable, and can help meet audit evidence requirements. Every action routed through AgentKey is recorded with timestamps, agent identity, tool called, and outcome. The evidence is tamper-evident rather than tamper-proof: verification detects any alteration to the stored record, but it does not prove the signing keys were never compromised, and it does not cover actions taken outside AgentKey.

AgentKey

AgentKey · Protocols

MCP Security

MCP security is the set of controls that protect Model Context Protocol connections, the standard way AI models and clients discover and call external tools, covering tool vetting, authorization, credential handling, and audit logging.

By AgentKey · Last updated 2026-10-08

Why MCP needs its own controls

The Model Context Protocol lets a model dynamically discover and call tools a client exposes. That flexibility is exactly what makes it powerful and what makes it risky: the set of tools is not fixed at build time, and the credentials the bridge uses are privileged.

Controls that matter

Authorization: every tool call through the bridge is checked against policy, not just the tools known at config time.
Tool vetting: tools the bridge exposes are scored and can be blocked when revoked.
Credential isolation: upstream credentials are stored encrypted and proxied, never handed to the model.
Audit: every call is recorded with the same evidence chain as SDK calls.
Mode: observe records without blocking; enforce blocks and escalates.

A bridge, not a bypass

A secure MCP bridge applies the same authorization and evidence pipeline to MCP calls that the SDK applies to direct calls. There is no separate, weaker policy path for protocol-based tool use.

Protocol pivoting and the trust boundary

MCP secures the client-to-server hop. It does not define a control over the earlier hop where a model turns a suggested tool name and argument values into an actual call, and it does not define one over the hop where one agent delegates work to another over a different transport such as Agent-to-Agent (A2A).

Protocol pivoting exploits the gap between those hops: an attacker who gets a foothold through one protocol can pass malicious instructions to an agent that forwards them over another, escalating into capabilities only reachable via the second protocol. Each protocol checks its own front door while nobody watches the hallway between them.

The consequence is that per-call authorization cannot be solved at any single transport layer. It has to run in the client, ahead of the tool call, where the concrete tool name and argument values are known, and record the decision as audit evidence.

Where AgentKey fits

AgentKey speaks MCP. Point a Claude, Cursor, or custom MCP client at the AgentKey bridge and every tool call flows through the same authorization, risk, and evidence pipeline as the SDK. Upstream credentials are encrypted and proxied.

Limitations

MCP controls sit at the client or bridge hop. A client configured to call upstream tools directly, without routing through the bridge, is outside the policy.

Credential isolation keeps upstream secrets from the model, but it does not by itself decide which calls are safe; authorization still applies separately to each call.

Tool vetting scores a tool on what it can do and who publishes it. A low-risk score is not a guarantee the tool is benign, and a revoked tool only blocks calls that reach the bridge.

Primary sources

Frequently asked questions

What is MCP security?

The controls that protect Model Context Protocol connections: authorizing every tool call through the bridge, vetting tools, isolating upstream credentials, and audit logging each call.

How are MCP calls authorized?

Through a bridge that applies the same policy and evidence pipeline as direct SDK calls. There is no separate, weaker path for protocol-based tool use.