Security

Security built into the architecture

Every agent has an explicit tool allowlist, every sensitive action requires approval, every decision is traceable, and every workspace is isolated. Security isn't a layer — it's the foundation.

Request beta access See the platform

Why role-based agents are safer

Some setups centralize everything into one broad-access agent. DeckCrew intentionally splits responsibility across specialized AI agents so permissions stay tight and failures stay contained.

Area	Single broad-access agent	DeckCrew agent model
Access scope	One agent often holds broad tool and credential access.	Each AI agent is scoped to specific channels and capabilities.
Blast radius	A bad prompt or bad call can impact many systems at once.	Impact is limited to the AI agent role that performed the action.
Operational control	Policy changes can affect every workflow globally.	You adjust permissions per AI agent, without global side effects.
Audit clarity	Harder to understand which responsibility layer acted.	Per-agent trails clearly show who did what and when.

Least privilege by default

AI agents start narrow and gain access only when it is needed.

Role separation over mega-prompts

Planning, coding, research, and outreach can be isolated across different AI agent roles.

Explicit capability controls

Tool and action permissions are toggled per AI agent, not inherited globally.

Trusted identity gating

Sensitive tools can require trusted identity, with operator-controlled trust state in Bridge.

Human confirmation for critical actions

High-risk mutations can be gated before execution.

Tool governance

Every agent has an explicit allowlist

Agents can only use tools that are explicitly allowed for their role. If a tool isn't on the list, the runtime blocks it — regardless of what the agent tries to do.

Per-agent allowlists Each agent has its own list of permitted tools and capabilities.
Per-provider scoping Block entire providers or individual tools within a provider.
Runtime enforcement The engine enforces permissions, not the agent's prompt.
Confirmation gates Even allowed tools can require human confirmation before execution.

AGENT_PROVIDER_TOOL_SCOPE_JSON for per-agent policy layering. Runtime-owned approval flow with deterministic args_hash and bounded result_summary. Raw MCP tools require reviewed-overlay selection before becoming usable.

Identity trust

You control who can trigger what

New users start untrusted. They can ask questions and interact, but sensitive tools are blocked until you mark them trusted. Trust is checked per tool, not just at login.

Trust gating per user Mark identities as trusted or untrusted from the Bridge.
Per-tool enforcement Trust-required flag checked at execution time, not just at access.
Identity scoping Apply different soul overlays per user, channel, or email.
External-safe Expose agents to customers without risking unauthorized mutations.

Persistent identity trust state via IDENTITY_UPSERT. Mutating tools blocked for untrusted identities with explicit denial reasons. Operator-controlled trust state in Bridge Identity panel.

Audit trail

Every action is traceable

Every tool call, every approval decision, every memory access is logged with full context. When something goes wrong — or right — you can trace the complete decision chain.

Execution telemetry Correlated execution threads showing plans, outcomes, and tool runs.
Memory attribution Every reply shows which memory lanes contributed to the answer.
Tool audit events Provider, arguments, result, and timing for every tool call.
Approval trail Who approved what, when, and with what context.

Plan-ID-correlated execution threads, per-lane continuity attribution, tool audit events with deterministic args_hash and provider attribution, and approval read APIs with full context.

Behavioral safety

Automated testing catches regressions before release

DeckCrew runs automated behavior tests covering memory safety, cross-agent leakage, soul drift, identity handling, and proactive presence policy. Issues get caught before they reach your agents.

Soul eval scenarios Test continuity, safety guardrails, and memory handling automatically.
Cross-agent leakage checks Verify that one agent's context doesn't bleed into another.
False memory detection Catch agents that claim to remember things they shouldn't.
Regression gates Tests run before every release as a CI quality gate.

Scenario-based soul eval runner covering continuity attribution, bounded context inspection, identity/memory introspection, shared-memory forget behavior, safety guardrails, and proactive presence policy regressions. Machine-readable KPI reports with budget thresholds.

Isolation

Your workspace is completely separate

Every company runs in its own isolated workspace. Agent data, knowledge bases, configurations, and audit logs are never shared or accessible across organizations.

Workspace isolation Complete separation between organizations at the runtime level.
No data sharing We never train on your data or share it across workspaces.
Provider key isolation Provider credentials are scoped per workspace and handled through secure secret storage.
Regional deployment Choose where your workspace runs geographically.

Per-workspace runtime isolation, engine-managed agent wakeup within workspace boundaries, encrypted credential storage, and namespace-scoped data access.

Security FAQ

Security questions

What happens if an agent tries to do something it shouldn't?

It gets blocked. Each agent has an explicit list of allowed tools and capabilities. If a tool isn't on the list, the agent can't use it — the runtime enforces this, not the agent's prompt.

Can untrusted users trigger sensitive actions?

No. New users start as untrusted. They can chat and ask questions, but tools marked as trust-required are blocked until an operator marks that identity as trusted in the Bridge.

How granular are the approval gates?

Per tool. You can require approval for sending emails but allow reading them. You can require approval for opening a PR but allow reading code. Each capability has its own confirmation setting.

Can I see exactly what an agent used to make a decision?

Yes. Every reply includes continuity attribution showing which memory lanes contributed: the current conversation, customer history, shared knowledge, or a saved playbook. Execution telemetry shows every tool call with provider, arguments, and result.

What if an agent's personality drifts over time?

The soul system tracks revision history. You can inspect how the agent's personality has changed and roll back to any previous version instantly.

Is data isolated between companies?

Yes. Every company runs in its own isolated workspace. Agent conversations, knowledge bases, configurations, and audit logs are completely separate.

Do you test agent behavior automatically?

Yes. DeckCrew runs automated soul evaluation scenarios covering continuity attribution, memory safety, cross-agent leakage, identity introspection, and proactive presence policy. Tests run before every release.