Execution identity
The agent proposes work.
A scoped execution API key starts Tasks, requests checkpoints, and records results. It cannot approve its own REVIEW action.
Security and trust
The Argos
security model.
Control is credible when you can see who has authority, where a change is held, and what evidence supports the outcome. Those boundaries are part of the Argos alpha.
Human reviewerJudgment
Short-lived human session
Authorized decision
ARGOSTask-relative control
Proposed operation
Coding agentExecution
Scoped execution credential
Agent cannot self-approve. Human authority is checked separately.
Human identity
The reviewer supplies judgment.
A short-lived human session identifies the reviewer. The server rechecks organization membership and existing decision permissions.
Verification source
Repository state supplies proof.
The independent verifier reads actual Git and filesystem state and runs the declared checks. Agent completion claims cannot certify success.
Before mutation
The supported launcher checks the control boundary.
The Codex alpha uses a dedicated configuration with PreToolUse interception and PostToolUse result reconciliation. Required hooks, entrypoints, credentials, and verifier availability are checked before controlled work starts.
01 / Customer repository
Codex reads through the bounded reader and proposes a supported apply_patch update.
02 / Argos control plane
Minimized operation metadata is checked against deterministic Task scope before mutation.
03 / Controlled continuation
Authorized work continues through its intended invocation. PROTECTED stays blocked; REVIEW waits for a human.
ARGOS CONTROL NOT ACTIVE
When required control components cannot be validated, the supported launcher refuses to start the controlled Codex session.
Argos cannot control an uninstrumented agent, an unrelated background process, or a session launched outside this boundary.
Minimized engineering data
Enough context to decide. Bounded evidence to inspect.
What the supported flow records
- Repository-relative target paths and proposal identities.
- Task/run, operation, agent, and scoped project relationships.
- Policy decisions, human choices, and execution state.
- Hashes, check outcomes, and bounded diagnostics.
What does not belong in evidence
- API keys, human access tokens, or private keys.
- Environment file contents or unrestricted repository exports.
- Unnecessary raw patches or unbounded command output.
- Credentials embedded in Task or Evidence URLs.
Truthful results
An uncertain outcome never becomes success.
Authorization, execution, and verification are distinct states. Generic external callbacks and result recording are not one atomic transaction; an uncertain result must not trigger a blind retry.
Every required deterministic check and declared repository outcome passed.
A required engineering condition was conclusively false, even if the patch executed successfully.
Repository truth or required checks could not be established because of environment or infrastructure failure.
Access and current limits
Know the boundary before you connect.
Scoped access
Execution keys are limited by organization, project, agent, and integration channel. A key authenticates instrumented traffic; it does not automatically observe an agent.
Protected history
Task and Evidence links require authentication and authorized workspace access. Possession of a URL grants no access.
Current alpha
Codex 0.143.0, one repository, and one existing-file apply_patch update per operation. REVIEW continuation is process-bound. Verification proves the declared deterministic contract.
Keep local human credentials separate from agent execution credentials. Evaluate the repository, declared checks, reviewer access, and supported launch configuration before a pilot.
Your next engineering Task
AI is getting more capable.
Your supervision model should too.
Start with Codex, one repository, and a boundary you can inspect.