Security at AgentKey

AgentKey evaluates every action an AI agent wants to take against the workspace owner's policy before the action reaches an external tool or API, records the decision and the execution as evidence, and lets a third party verify that evidence was produced by AgentKey and not altered afterward.

Scope and non-goals: AgentKey is not an identity provider, not a secret vault for your infrastructure, and not a replacement for your own application security. It authorizes and records agent actions against external tools and APIs. It is a hosted service today; self-hosting is not currently supported.

1. Your agent calls the SDK (or the MCP server, or the raw HTTP API) before performing an action.
2. The call is sent over HTTPS to the authorize endpoint with a Bearer API key for the agent.
3. AgentKey hashes the presented key and looks it up by hash. Invalid, revoked, or unknown keys are rejected.
4. The agent's permission policy is evaluated: allow, ask, or deny, with parameter-level conditions.
5. Risk signals are scored; high-risk actions escalate to human approval, and tool trust and input integrity checks can block unsafe calls.
6. The decision is returned and recorded as a hash-chained evidence event paired with the eventual execution record.
7. The tool or API is called by your agent only if the decision was allow.
8. At session close, the Merkle root of the event chain is signed (HMAC-SHA256 attestation, plus an Ed25519 signature), the session's own metadata is signed as well, and the root is anchored into a per-workspace chain that detects deleted sessions.

Application users sign in with email and password plus a one-time code verification step, or with Google sign-in. Password reset requires a single-use token delivered by email. Session management and credential storage are handled by the hosting platform's authentication service; AgentKey does not implement its own password storage.

Agents authenticate with per-agent API keys presented as Bearer tokens. Keys are validated by SHA-256 hash lookup; the plaintext key is never stored server-side after creation.

Policies are explicit per agent and per action: resource and action pairs with allow, ask, or deny decisions. Allowed actions can be narrowed by parameter conditions, for example maximum amounts or allowed domains. Actions marked ask pause for a human decision in the dashboard before they proceed.

Additional layers: risk scoring can escalate any decision to approval; a tool trust registry scores and can quarantine connected MCP tools; input integrity scanning flags prompt injection in content an agent ingests; global block policies can deny domains or patterns for the whole workspace; and delegation chains let one agent pass a strictly scoped subset of its own authority to another agent, with server-side prevention of scope escalation and configurable depth and TTL limits.

Keys are generated server-side and returned exactly once at creation. Only a SHA-256 hash and a short non-secret prefix used for identification are stored. Keys can be revoked at any time, and a revoked key immediately fails validation and cannot authorize actions. Keys carry an environment tag (development, staging, production) and are scoped to one agent.

An API key is a credential. Never commit it to source control, paste it into chats, or embed it in client-side code. If a key may have been exposed, revoke it and create a replacement.

AgentKey fails closed. When the service cannot determine that an action is authorized, the decision is deny, never allow. This includes: the service being unreachable, timeouts, malformed requests, invalid or revoked API keys, missing identity, missing policy, evaluation errors, and database failures. The SDK applies the same rule client-side: on any error, timeout, or ambiguous response it returns allowed=false.

Unknown and error outcomes are never treated as allow, in the API, the MCP server, and both SDKs.

Every authorization decision produces a log record with: timestamp, workspace owner, agent identity, the API key identity (by internal reference, never the secret), tool, action, resource, the decision and its reason, risk level, and a hash of the parameters rather than the raw values. Execution records capture what the agent actually did, including result hashes and durations.

Evidence events are append-only. Every event is hashed under a canonical, versioned serialization; canonical version 2 covers all displayed fields, including sanitized argument previews, scan results, risk signals, and metadata. The session's Merkle root is computed at close. Closed sessions carry an HMAC-SHA256 attestation over the root, an Ed25519 asymmetric signature (enabled in production and publicly verifiable against the published Ed25519 key), and a signature over the canonical session metadata itself, so counters and session flags cannot be edited without detection. Events that appear after close are rejected as invalid rather than treated as signed evidence. Sessions are anchored into a per-workspace chain that detects deleted sessions. Verification recomputes everything from stored events and is available through the API and an offline verifier, without trusting the system that produced the records.

Fixed defect disclosure: between the introduction of the session metadata signature and September 11, 2026, that signature was produced by an implementation that signed a defective message (an engineering error, not a key compromise). Those signatures cannot be verified as valid. Sessions from that window are reported as carrying a known historical signature defect, never as tampered and never as valid; their event hashes, Merkle roots, and root signatures remain independently verifiable. Sessions closed after the fix are signed over the real canonical metadata digest and verify normally.

Honest limits: verification proves records were produced by AgentKey and were not altered after the session root was signed. It does not prove the signing keys are uncompromised, and evidence only covers actions that went through AgentKey; coverage numbers are reported per session.

The pipeline below is the implemented evidence path. Every step shown is confirmed by the running code; anything not implemented is listed under what this does not prove.

AgentKey signs closed evidence sessions using Ed25519. The private signing key is a server-side secret: it is never exposed in any response, export, or log. The corresponding public key is published and is all a third party needs to verify a signature. A symmetric HMAC-SHA256 attestation is recorded alongside it.

Key handling: a session signed under a key that is neither current nor retained verifies as incomplete (signed under a retired key), never as valid and never silently invalid. There is no automated rotation schedule; rotation is a manual operation, and retained previous public keys are listed above only when configured.

Administration actions are audited separately from agent evidence, in an organization-level audit log. Recorded events include: API key creation and revocation, permission policy changes, human approval decisions, agent creation, modification, and deletion, member invitations and role changes, membership suspension and removal, compliance exports, and denied access attempts. Each event carries the organization, acting user, target resource, result, source, and sanitized metadata. No secrets, credentials, or raw key material are ever written to audit events.

The audit log is viewable in the dashboard and the Organization page, filterable by action, result, and date range, and exportable as JSON by the SECURITY role and above. Audit events are deliberately separate from agent execution evidence: the audit log answers who did what in the control plane; evidence answers what the agent did.

Every record carries an owner reference, and access is enforced server-side by row-level security plus explicit ownership re-verification inside every write path. Sensitive writes run through service-role functions; a request referencing another organization's record returns not found, and the backend derives the caller's organization membership and role server-side on every protected operation. Client-supplied organization, user, or role values are never trusted. Frontend filtering is never the security boundary.

Workspaces are organized as organizations: each has one owner, and additional members can be invited with organization roles (see RBAC). The organization's data is anchored to the owner reference on every record, so cross-organization access is not possible; a user who is not a member of an organization cannot discover its existence or its resources. Direct evidence browsing in the UI remains owner-scoped; members access shared compliance data through the organization's filtered audit log and exports.

Five organization roles are enforced server-side from membership records, never from the frontend or client-supplied values:

• OWNER - full organization control, including role changes and member management.
• ADMIN - manage members, agents, API keys, policies, approvals, and exports. Cannot change roles or transfer ownership.
• SECURITY - view and export compliance data, inspect policies, resolve approvals, and revoke compromised API keys. No billing, member, or core policy modification.
• DEVELOPER - view organization agents and use the normal developer workflow. No key, policy, member, or export management.
• VIEWER - read-only access to the organization overview and audit log.

Existing single-user accounts are the OWNER of their organization; no behavior changed for them. Users may belong to multiple organizations; the data model supports this, and an organization switcher will be added when the UI requires it. The platform-level admin role is not sufficient by itself: management operations additionally require the organization role derived from membership.

What AgentKey stores: policy rules, decision and execution records, evidence events with hashes, key hashes and prefixes, account and subscription metadata, and sanitized metadata limited to primitive values. Tool arguments are stored as SHA-256 hashes by default; a per-agent opt-in can store a sanitized, truncated argument preview for debugging. Raw API keys, passwords, tokens, and private keys are never stored after creation or written to evidence records.

Encryption: all traffic is served over TLS. Credentials for connected MCP upstream servers are encrypted at the application layer with an authenticated cipher, with encryption keys held as server-side secrets. Database encryption at rest is managed by the hosting platform.

Retention: records are retained until the workspace is deleted. Configurable retention periods are not currently supported. Not currently supported: data residency selection, and customer-managed encryption keys.

The key validation endpoint enforces IP-level and per-key rate limits and degrades closed (rejecting requests) if the rate-limit backend fails. The authorize endpoint is metered per plan with usage counters, and public endpoints enforce input size and count caps. Signup hygiene rejects known scanner domains at the registration form; this is noise reduction, not a security control.

Reports are accepted through the contact channel on the Contact page. Process: acknowledge, investigate using the audit and evidence records, contain and remediate, then notify affected workspace owners with a summary. There is no formal response-time SLA commitment yet. Status communication happens on this page.

We welcome reports of vulnerabilities in the AgentKey application and API. Report through the contact channel on the Contact page, including reproduction steps and impact. Please do not test against other customers' workspaces, and do not run automated scanning against the service without prior permission.

We commit to acknowledging good-faith reports, working with you on remediation, and crediting you if you wish. We ask for a reasonable window before public disclosure. This is not a bug bounty program.

• Base44 (Wix) - application hosting, database, authentication, and runtime infrastructure.
• Paddle - payment processing and billing.

This list will be updated as the service changes.

The Enterprise Security Checklist states the implementation status of each security area. Inside the product, the dashboard shows live decisions, approvals, evidence, and security events; the Evidence page exports records for independent verification with the offline verifier.