Instrumented boundary
Argos starts when your agent reaches an explicit SDK checkpoint, orchestrator node, or execution gateway.
Security and trust
Control consequential AI actions without handing over unnecessary access.
Argos receives the minimum context needed to hold a consequential action, keeps customer-system credentials server-side, scopes access by workspace and project, and marks outcomes verified only after an independent external reread.
Security overview
How Argos protects systems, credentials, and operational evidence.
Argos is built around explicit checkpoints, minimized context, server-side authority, authenticated human decisions, and verification after the external system is reread.
Minimum context
Send the action, business object, risk metadata, and redacted summary needed for review. Avoid raw secrets and unnecessary payloads.
Human resolution
When policy or uncertainty requires a decision, Argos presents a case to authenticated reviewers instead of letting the agent continue silently.
Verified completion
Argos treats a workflow as complete only when the external source of truth is reread and the expected outcome is confirmed.
Data minimization
Only the data Argos needs.
A good integration sends enough information to evaluate and verify the action without sending broad customer data by default.
Needed for control
- Organization, project, workflow, and agent identifiers
- Tool, action, target type, and risk-relevant metadata
- Redacted or minimized business summary
- Policy decision, reviewer choice, and continuation state
- External readback status and business-readable evidence
What Argos should not need
- Raw API keys, passwords, access tokens, or private keys
- Full customer tables or unrestricted exports
- Complete email inboxes or unnecessary message bodies
- Unredacted prompts when a safe summary is sufficient
- Customer-system credentials in browser-visible code
Credentials
Credentials stay server-side and protected.
Argos should never require customer-system credentials in browser code. Privileged operations stay server-side and are logged with redaction.
- Customer-system credentials must stay server-side.
- Browser users cannot choose adapter mode, reveal secrets, or enable hosted mutations.
- Continuation authority is bounded to a specific approved action and fixture or tenant scope.
- Logs and diagnostics should report configuration presence without printing secret values.
Tenant isolation
Access stays inside the intended tenant boundary.
Workspace data, API keys, reviewer decisions, and hosted test mutations must remain scoped to the exact organization, project, agent, and workflow allowed by policy.
- Authenticated users must have trusted membership before accessing workspace data.
- API keys are scoped to the organization, project, and allowed agent or workflow boundary.
- Hosted fictional CRM mutations require exact fictional identifiers and explicit test authorization.
- Direct-route access should not reveal protected app data without a valid session.
Bounded execution
One decision releases one controlled action.
Approval does not equal verified success. A continuation grant authorizes only the selected next action, and completion depends on readback from the external source of truth.
Trust-boundary diagram
- 01
Customer agent
Runs in the customer environment and calls an instrumented checkpoint.
Customer runtime
- 02
Argos action checkpoint
Receives minimized metadata and policy-relevant context.
Server-side Argos
- 03
Policy and reviewer
Deterministic policy and authenticated reviewer decision.
Human control
- 04
Bounded authorization
A continuation grant permits one approved next action only.
Server-side secret
- 05
Customer system
The external CRM, billing, email, or internal API performs the side effect.
External system
- 06
External readback
The source of truth is reread before issuing verified success.
Independent verification
- 07
Evidence
Business-readable record with technical details behind disclosure.
Workspace evidence
Evidence
Evidence leads with the business conclusion.
Evidence should lead with the business conclusion and keep sensitive or implementation-shaped metadata behind progressive disclosure.
- Reviewer decision and timestamp
- Controlled continuation state
- Selected and unselected record readback
- Mutation count or equivalent idempotency evidence
- Redacted business conclusion before technical metadata
Verification
Success requires an external reread.
Argos verifies an outcome by rereading the selected and unselected external records, checking the expected change, and confirming duplicate continuation did not create another effect.
Selected record
Reread and expected change confirmed
Unselected record
Reread and confirmed unchanged
Mutation evidence
Mutation count or idempotency receipt checked
Failure handling
Uncertainty is withheld from success.
When provider responses and external readback disagree, Argos should surface conflict or reconciliation instead of issuing a false success.
Verification conflict
Provider reported success, but reread does not match the intended outcome.
Reconciliation required
A timeout or connection loss made the external state uncertain. No blind retry is performed.
Execution failed
A known failure is recorded separately from approval and verified success.
Shared responsibility
Security is a shared operating discipline.
A secure pilot depends on the customer choosing the right workflow boundary, limiting credentials, redacting payloads, and defining the source-of-truth readback.
- Instrument only workflows where the next consequential side effect can be paused.
- Use scoped credentials and rotate them through your normal secret-management process.
- Send minimized summaries instead of unnecessary raw payloads.
- Assign reviewers who understand the business consequence of each action.
- Confirm which external record proves the outcome.
Current limitations
Clear limits before rollout.
Argos is deliberately specific about what the MVP proves. These boundaries should be reviewed before any production pilot.
- Argos does not control uninstrumented agents or arbitrary background processes.
- Argos does not guarantee rollback across every external system.
- A successful provider response is not treated as verified completion by itself.
- Customers remain responsible for configuring the checkpoint, credential scope, source-of-truth readback, and reviewer access.
- Formal compliance commitments are evaluated separately during a customer security review.
Security contact and pilot review process
Bring one workflow, one credential boundary, and one external source of truth.
A pilot review should confirm the checkpoint location, data minimization plan, reviewer roles, credential scope, failure handling, and verification source before live use.