Abhed — Red-Team Engagement Scope

Status: scoping document. The engagement itself has NOT been performed.

This exists to be handed to a security firm or an internal offensive team. It is not evidence of testing — internal/redteam is the automated suite, and that suite proves only that Abhed resists the attacks its author thought of. The whole reason to commission a human engagement is that the set of attacks a defender imagines is systematically smaller than the set an attacker finds.

Why this is not optional

The design research that informed Abhed produced zero verified claims about agent sandboxing, and two candidate claims were refuted under adversarial verification. The isolation posture of comparable agents is therefore unknown, not known-good. Abhed's controls were built from first principles and tested against 16 self-authored attacks; that is a floor, not a clearance.

What Abhed is

An agent that reads untrusted text and executes code derived from it, on infrastructure holding source code, credentials and customer data. The interesting property for an attacker: the model is an untrusted input channel that reaches a code-execution primitive.

Target of evaluation

Deploy per docs/ops/air-gap.md with sandbox.min_tier = container, OIDC auth, and Postgres storage. Provide the team two tenants and three users at differing privilege.

Priority 1 — the claims most worth breaking

Each is a property Abhed asserts. Breaking any one is a critical finding.

1. Workspace confinement. No path, symlink, race, or shell construction lets the agent read or write outside its workspace.
2. Egress denial. With allow_network: false, no channel reaches the network — including DNS, ICMP, unix sockets to host daemons, and abuse of a permitted toolchain (a package manager's fetch, a language runtime's HTTP client).
3. Deny is absolute. No mode, rule ordering, argument encoding, or command chaining produces execution of a denied pattern.
4. Managed policy cannot be escalated past. A local config or a crafted request cannot obtain permissions the org-level config withholds.
5. Tenant isolation. No API call, SSE stream, session id guess, or SQL path returns another tenant's events. Note RLS is enforced with FORCE; verify a compromised app role cannot disable it.
6. Untrusted content never becomes instruction. Injection via repo files, tool output, MCP responses, or brokered search results does not cause the agent to exceed its granted authority. Assume injection sometimes succeeds — the question is whether success is contained.

Priority 2 — supply chain and protocol

1. MCP servers are hostile by assumption. A malicious server should not be able to shadow a native tool, poison the model's context through tool descriptions, or pivot to the host.
2. Token verification. alg:none, algorithm confusion, key-id confusion, JWKS poisoning, expired/replayed tokens, issuer substitution via a mirrored discovery document.
3. Bundle integrity. Substituting a binary in a signed bundle; downgrade to an older signed bundle; tampering that preserves the archive digest.

Priority 3 — availability and resource abuse

1. Fork bombs, disk fill, memory exhaustion, context flooding, catastrophic regex, subagent fan-out exhausting budget, and an unbounded agent loop.

Explicitly in scope

• Chaining low-severity issues into a meaningful compromise. This is where automated suites are weakest and human testers are strongest.
• Social-engineering the model rather than the human: crafting repository content that induces the agent to act against its operator.
• Timing, race and TOCTOU conditions in the read-before-edit guard, checkpoint writes, and the approval flow.
• Abuse of legitimate features: /undo to restore a file the operator deleted, /export to write outside the workspace, subagents to bypass a budget.

Out of scope

• Denial of service against the model endpoint itself (that is capacity, not security).
• Physical access, and attacks on the underlying OS or hypervisor.
• Social engineering of staff.

Rules of engagement

• Test against a dedicated deployment with synthetic data. Abhed's audit log is append-only by database trigger; do not attempt to clear it between attempts — a full trail is useful evidence.
• Report critical findings immediately rather than at the end.
• Retain full session transcripts. Every session is replayable via /v1/sessions/{id}/replay, which should make reproduction straightforward.

Deliverables

1. Findings with severity, reproduction steps, and the specific claim above that each one breaks.
2. An explicit statement for each Priority 1 claim: broken, not broken under test, or not tested. "Not broken under test" is the strongest result available and should not be reported as "secure".
3. Regression tests we can add to internal/redteam, so a finding cannot silently return.

Suggested effort

Two testers, three weeks: one week on Priority 1 with source access, one on Priorities 2–3, one on chaining and reporting. Source access is recommended — Abhed is intended to be deployed by organisations who can read it, so a black-box test models the wrong attacker.

Current automated coverage

internal/redteam covers 16 attacks across the areas above, all currently blocked. Treat that as the regression floor: anything it catches is already fixed, so the engagement should start where it stops.