Encrypted secret custody
Secret values are encrypted before database write with AES-256-GCM envelope encryption. Workspace data keys are wrapped separately from encrypted values.
Security at ScopeHold
Designed for managing agent access to live credentials.
ScopeHold protects secrets with encrypted custody, direct grants, scoped Agent Keys, access history, and expiry controls for individual agents.
trust posture
Secret storageEncrypted before database write
Agent KeysOne-time issue, hash stored
AccessDirect grants per secret
AuditSuccesses and denials recorded
Protection model
Store the key once. Let the right agent use it. Keep the record.
ScopeHold keeps the sensitive value separate from the agent task. Storage, grants, resolution, and auditing each have a specific job.
Direct secret grants
Seeing a project or provider does not reveal its secrets. Direct grants control which member or agent can reveal or retrieve each value, with agent access managed individually.
Append-only audit trail
Human reveals, agent retrievals, denials, grants, revokes, role changes, provisioning events, and security settings changes are recorded without storing raw secret values.
Humans and agents
One system, two access paths.
Members can reveal what they need in the dashboard. Agents can retrieve only the secrets directly granted to them, or run commands with values injected at runtime.
Members
Human access
Members sign in with Google or magic link. Workspace roles control management ability, and admins can require authenticator MFA before sensitive secret fields are revealed in the dashboard.
- Google and magic-link sign-in
- Role-based workspace access
- Optional MFA before human reveal
Runtime identities
Agent access
Agents use one-time provisioning to receive Agent Keys, then retrieve only the secrets they have been granted. Agent Keys are shown once at setup and stored by ScopeHold only as hashes.
- One-time provisioning prompts
- Agent Keys stored as hashes
- Optional key expiry and notifications
Runtime injection
Run commands without pasting secrets into chat.
scopehold run lets agents use granted secrets at runtime without copying provider credentials into prompts, chats, shell history, or project files.
$ scopehold run -- deploy
retrieved: STRIPE_SECRET_KEY
scope: project / release-agent
audit: resolve.success recorded
raw value not printed by ScopeHold
Audit trails are useful without becoming another secret store.
ScopeHold records security events and sanitized metadata, not credential payloads. That gives builders and teams a practical review trail for both successful and denied access.
- Secret reveals and agent retrievals
- Denied access attempts
- Secret grants, revokes, and role changes
- Provisioning prompt redemption
- Security setting changes
Platform safeguards
ScopeHold uses encrypted storage, security headers, rate limits, protected internal endpoints, and careful payload handling to reduce abuse and resource exhaustion.
Open client
The official ScopeHold CLI is public, so builders can inspect the runtime client that provisions agents, lists inventory, retrieves granted secrets, and runs commands with scopehold run.
View the CLI source on GitHubFound a vulnerability?
Email the security contact. Please do not include raw secrets, Agent Keys, or customer credential payloads in the report.
security@scopehold.com