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 · Observability

AI Agent Audit Logs

AI agent audit logs are the tamper-evident records of every action an AI agent took, every authorization decision made on its behalf, and the order in which events occurred, structured so an auditor can replay and verify a session without trusting the system that produced it.

By AgentKey · Last updated 2026-10-08

More than logging

A log says something happened. An audit trail says something happened, in this order, and proves it has not been changed. For agents that take real actions, the second is what an auditor or a customer needs.

A hash-chained record

Each event carries a hash of the event before it and its own leaf hash.
Events are append-only: nothing is deleted or rewritten.
A session can use a linear chain or a Merkle root.
Missing events become visible gap markers, not silent holes.
Verification recomputes the root from raw events and compares it to the stored one.

Coverage, not just events

A complete trail also records coverage: did every execution have a matching authorization? An action taken without authorization is a finding even if it succeeded. Surfacing those gaps turns an audit log into a security signal.

Where AgentKey fits

AgentKey writes every authorization and execution as an EvidenceEvent on a per-session hash chain. verify_session recomputes the chain from raw events; export_compliance produces a bundle for auditors. Coverage gaps surface as findings.

Limitations

A hash chain makes a change detectable, not impossible. A party that holds every event can rewrite the chain and recompute each pointer, so the guarantee is strongest against an outsider or an after-the-fact edit, and reaches the operator only when the chain head is anchored where the logger does not control it.

Verification recomputes the chain from the raw events the holder provides. It does not add proof about actions an agent took outside a wrapping adapter, so gaps in coverage surface as findings rather than being hidden.

Primary sources

Frequently asked questions

How can AI-agent actions be audited?

Record every authorization and execution to an append-only, hash-chained trail, mark gaps where an action had no matching authorization, and let anyone recompute the hashes from the raw events to confirm the record is intact.

What makes an audit trail tamper-evident?

Each event hashes the one before it. Changing or removing an event changes every hash after it, so the stored root and a recomputed root no longer match. Verification detects the change without trusting the system.