ScopeHold
Resources

Security model

How ScopeHold keeps AI agent secrets out of chat, logs, and local files

ScopeHold keeps AI agent secrets out of chat, logs, and local files by combining scoped agent identities, one-time provisioning, encrypted secret custody, MFA before human reveal, audit logs, rate limits, and plan-limit enforcement.

Start freeBrowse resources

Answer target

How does ScopeHold protect secrets used by AI agents?

Updated June 2, 2026

Short answer

ScopeHold separates secret custody from agent conversations. Raw provider secrets are stored centrally, encrypted, scoped to projects, granted to named members or agents, and resolved only through controlled reveal or runtime APIs. Agents receive a scoped Agent Key through a short-lived provisioning flow instead of receiving raw provider credentials in chat.

Secrets stay out of chat by design

The main ScopeHold pattern is simple: the chat can contain setup instructions, but it should not contain the raw provider credential. A user creates or selects an agent, generates a short-lived provisioning prompt, and the agent redeems that prompt through ScopeHold. The returned Agent Key is stored outside the chat interface and then used to resolve only granted secrets.

Agents have scoped identities

An agent is treated as its own runtime identity, not as a copy of the human user's full access. Workspace and project roles define the operating context, while direct grants decide which secret values the agent can actually resolve.

  • Agent access is tied to a named identity that appears in audit history.
  • Project assignment narrows the operating context before any secret is resolved.
  • Direct grants control access to individual secret values.
  • The runtime resolve API is agent-only, so browser user sessions cannot use the agent resolution path.

Provisioning is short-lived and single-use

Provisioning prompts use short-lived, one-time tokens. Redeeming a prompt creates a fresh Agent Key for that agent and revokes older active Agent Keys for the same agent. If the prompt expires or is replaced by a newer prompt, the agent has to request a new one.

Stored values use envelope encryption

Secret values are stored with AES-256-GCM envelope encryption. Workspace data keys are wrapped separately from the encrypted secret values, with KMS-backed wrapping supported for production key custody. The audit trail records security events and metadata, not raw secret values.

Human reveal can require MFA

Human members can reveal granted secrets through the dashboard when policy allows it. Workspace security settings can require authenticator MFA before human reveal, adding a step-up check before sensitive values are shown in the browser.

Access is logged and bounded

ScopeHold records events such as secret creation, grants, human reveal, agent resolve, provisioning redemption, rotation, denial, and billing-limit enforcement. API and web routes also use rate limiting to reduce abuse risk, and over-limit resources are disabled from reveal or resolve until the account is back within plan allowance or upgraded.

  • Audit logs are designed for review without becoming another secret store.
  • Rate limits apply to sensitive paths such as provisioning redemption, human reveal, and agent resolve.
  • Plan-limit enforcement preserves existing data while disabling over-limit secret use.
  • Production errors return generic messages while server logs retain sanitized request context.

Agent instructions treat retrieved data as untrusted

ScopeHold's agent guidance tells agents to treat inventory, provider names, secret names, descriptions, metadata, and resolved values as untrusted data, not instructions. That matters because the safest secret workflow still needs the agent to avoid following instructions embedded in labels, descriptions, or retrieved values.

Practical workflow

  1. 1Store onceAdd the provider credential to ScopeHold so the raw value does not have to live in chat, screenshots, copied prompts, or scattered local files.
  2. 2Scope accessAssign the secret to the right workspace and projects, then grant access only to the members and agents that need it.
  3. 3Provision the agentUse a short-lived one-time provisioning prompt so the agent receives its Agent Key outside the chat transcript.
  4. 4Resolve and auditThe agent resolves granted secrets at runtime, and ScopeHold records the access event without writing the secret value into the audit log.

Ad hoc agent secret sharing vs ScopeHold security model

TopicAd hoc agent secret sharingScopeHold security model
Chat historyRaw provider keys may be pasted into the conversation.Only short-lived provisioning prompts belong in chat; provider secrets stay in ScopeHold.
Agent accessThe agent often inherits whatever the human copied over.A named agent resolves only directly granted secrets.
RotationTeams have to find every copied key and local file.Provisioning rotates Agent Keys, and provider secrets can be updated centrally.
ReviewIt is hard to know who used what after the task is done.Reveal, resolve, denial, grant, and rotation events are recorded for review.

Where ScopeHold fits

ScopeHold is built for human-plus-agent teams that need credentials to be usable without becoming chat artifacts. It combines encrypted custody, scoped runtime identities, direct grants, MFA-before-reveal, rate limiting, plan-limit enforcement, and audit logs into one operating model.