Boundaries

Understand what ExecWarden controls, stores, and logs.

Workspace ownership, sandboxed execution, scoped secrets, policy-gated capabilities, approval checkpoints, transcripts, and operational logs define the trust boundary.

What ExecWarden Protects

ExecWarden is built for the moment when an agent needs to touch a real company system but should not receive a broad provider credential. The protected object is the authority path: who the caller is, which capability it can invoke, what scope applies, whether a person must approve the exact call, and what evidence remains afterward.

Agent identities	Name the external MCP client, hosted session, workflow run, or other caller. Identity lifecycle, expiry, disable, regeneration, and revocation stop future calls through ExecWarden.
Canonical grants	Bind one subject to one capability with mode, scope, provenance, optional expiry, and use limits. Off is the absence of a grant.
Approvals	Ask mode pauses a specific risky call before execution. Approval replay reuses the stored request and revalidates the live authority path.
Activity	Records the caller, capability, canonical grant evidence, provider/package action, status, timestamps, and configured payload capture for investigation.
Secret boundaries	Agents call gateway capabilities instead of receiving raw provider OAuth tokens, PATs, or package API keys. Package code can read only declared package-local secret names.

Main Threats

The model assumes agents can be useful and wrong at the same time. Prompts, issue bodies, documents, webpages, package responses, and provider data can all contain instructions that should not become authority.

Prompt injection	External content tells the model to use an allowed tool in a way the human did not intend.
Confused deputy	A model tries to use the workspace, provider account, or package secret behind ExecWarden for a different resource or user goal.
Over-broad grants	A caller receives too many tools, too wide a repo/provider scope, or standing access after the task ends.
Approval fatigue	A human approves a risky call without enough context, or assumes approval is the only safety boundary.
Package/runtime abuse	Self-authored package code or sandboxed work can still send data to allowed destinations when granted secrets, fetch, git, browser, or shell access.
Operator compromise	Admins, deployment hosts, databases, OAuth control planes, backups, DNS, and source control remain inside the operational trust boundary.

Controls

Scope before approval	Keep the grant narrow first: one repo, branch pattern, provider account, package action, imported MCP tool, workflow, or time window. Approval should be the last check, not the only check.
Ask for risky writes	Put PR create/update/merge, comments, deploys, calendar mutations, expenses, package writes, and imported MCP writes in Ask mode until the action is routine and low risk.
Exact approval replay	The pending request stores the action and arguments shown to the reviewer. Approved execution uses that stored request and rechecks current grants, scope, policy attachments, and caller source. It does not prove the upstream branch, ticket, file, package response, or provider record stayed unchanged between review and execution.
No raw provider secrets for agents	Agents call gateway capabilities. Provider tokens and package secrets stay workspace-owned; package runtime code reads only secret names declared by its manifest.
Runtime isolation	Package JavaScript and Wasm do not run as Node imports and do not receive direct database, process, environment, or filesystem access. Hosted work runs through sandbox volumes or compute hosts.
Revocation and expiry	Agent identities and grants can expire or be revoked. Disable, regenerate, or revoke identities when a task ends or a token is exposed. Disconnect or rotate upstream provider credentials when needed.

Evidence

A good first run should leave evidence that a second engineer can inspect without trusting the model's summary. ExecWarden records product evidence, but it is not a replacement for provider audit logs, immutable compliance retention, or a SIEM export.

Before the run	Identity detail shows the named caller, active grant count, expiry, connected MCP clients, and recent Activity.
During approval	The approval shows the capability, requested arguments, source session or workflow, requester context, and decision.
After the call	Activity records the caller, capability, grant evidence, provider/package action, status, timestamp, duration, and configured request/result capture mode.
Provider-side record	GitHub PRs, provider audit logs, remote MCP server logs, and package provider responses remain the source of truth for what changed upstream.
Cleanup check	Identity status plus old-token retry failure shows future calls through ExecWarden are stopped. Revocation does not undo external actions that already completed.

Limits

Not model safety

ExecWarden limits tool authority; it does not make a model understand intent, detect every malicious instruction, or choose the right business action.

Not provider rollback

Revocation stops future calls through ExecWarden. It does not undo PRs, comments, deploys, calendar edits, expenses, package calls, or remote MCP actions that already happened.

Not automatic DLP

Allowed reads and writes can still move sensitive data when policy permits that path. Scope reduces blast radius; it does not classify every piece of business data.

Not package marketplace trust

Capability packages can be registered, tested, published, granted, and invoked, but there is no public marketplace, review process, signing, provenance verification, or host-proxied secret handle layer for third-party packages today.

Not a host compromise boundary

A compromised host, Docker daemon, admin account, database, OAuth control plane, DNS account, source-control admin, backup, or LLM-provider account can bypass product-layer controls.

Not guaranteed compliance retention

Activity, transcripts, approvals, and operational logs are investigation evidence. Fixed retention, immutable logs, and SIEM export depend on deployment and operations choices.

Start read-only	Let the agent inspect one repo, provider record, package action, or imported MCP tool and produce a report before granting writes.
Add one write in Ask mode	Choose the single useful mutation: create a PR, comment, stage a package mutation, update a ticket, or run a workflow. Keep merge, deploy, delete, and admin actions separate.
Inspect evidence before widening	Check identity detail, grants, approval payload, Activity, provider result, and old-token retry behavior before adding broader scope.
Keep production different	Use shorter identity lifetimes, narrower grants, provider-side audit, deployment retention, and stronger sandbox or VM isolation before agents touch high-impact production systems.
Next question	Use GitHub Repo Quickstart for the concrete first setup, or Gateway Capabilities to review the authority model underneath it.