What could that agent reach?
The answer should not depend on how carefully someone filled in a form. Everything below is a property of how a harness is built. There is no configuration that turns it off, because there is no configuration that turns it on.
The shape of it
Nothing dials in.
The agent never sees the key
A trusted process holds the model credential in memory and proxies requests over loopback. The agent and every shell tool it spawns receive a dummy, so nothing they run can print the real key or an OAuth token.
Starting one and sitting inside it are different grants
An attached session is an interactive shell in the workspace, running as the agent, with the repositories checked out. So harness:attach is a permission your team grants separately from harness:create, because "may spin one up" and "may get a prompt inside it" are not the same trust.
Controls
What holds, and why.
No inbound network path
Not a restricted one. The harness security group has no inbound rules at all. The interactive session works because the runtime dials outward to the session gateway over an authenticated WebSocket. There is nothing to port-scan and nothing to expose by misconfiguration.
The agent cannot read any credential
A trusted process outside the agent holds every credential in memory, the model key and each connected tool, and proxies requests over loopback. The agent and every shell tool it spawns receive a dummy value or a local address, never a token. Nothing the model can be talked into running, by a repository or an MCP response or a prompt, can print one, because it never had one to print.
No cloud identity of its own
The harness task runs with no AWS task role, so it has no standing access to anything. Connect an account and it gets one thing: a credential minted on demand from a role you created in your own account, scoped to exactly the policy you wrote, expiring within the hour — never a stored key. Nothing durable is written down, and revoking the role in your console cuts off every harness immediately, without asking us.
Attaching is a separate grant
An attached session is an interactive shell inside the workspace, running as the agent, with the repositories checked out. So harness:attach is granted separately from harness:create. "May spin one up" and "may get a prompt inside it" are not the same trust, and the permission model says so.
Immutable versions
Every launch pins a template version: the raw document, its normalised form, and a content digest. Editing a template creates a new version and never reaches into a harness that is already running. Any harness can be reproduced exactly from its digest, which is what makes an incident reconstructable.
Deadlines are not optional
Every harness carries a time to live, defaulting to four hours, and the server caps it at eight. A reconciler enforces expiry and stops orphaned tasks. Per-tenant quotas bound how many can run at once, so a runaway fan-out is a rejected request rather than a bill.
Templates carry no credentials
A template names the tools it needs and never whose account opens them. The credential belongs to whoever launched it, is resolved at that moment, and is stored encrypted against that person, so a template can be shared, committed and reviewed without carrying anyone's access with it.
Append-only audit
Harness creation and teardown are written as audit events in the same transaction as the change itself, so the record cannot disagree with what happened. Every tenant-owned row carries its tenant, and every query is scoped by it.
Defined in code
The composition is a file. Its digest is its identity.
Editing a template mints a new version and never reaches into a harness that is already running.
apiVersion: quiv.dev/v1alpha1kind: HarnessFramemetadata:name: backend-reviewspec:runtime: pimodel:provider: anthropicid: claude-sonnet-4-5credential: session-setupttl: 4hsize: smallrepositories:- repository: github.com/acme/backendrevision: maindestination: backendmcpRequirements:- slacktoolRequirements:- githubactivityLog: truesummarize: true
Every launch pins an immutable version.
A version is deduped on the SHA-256 of the document itself, so the digest is the composition. Editing a template creates a new version; harnesses already running are untouched, and any harness can be reproduced exactly from its digest.
sha256:9f2c41d8e7b0…a3
Threat model
We treat all of this as hostile.
Not because we expect it to be, but because the design is only worth anything if it holds when it is.
A coding agent reads untrusted text and then takes actions. That is the whole job, and it means prompt injection is not an edge case to be filtered out but the normal operating condition. So the boundary is not "the model behaves". It is that a harness which has been fully talked into doing something still has no inbound route, no readable credential, and a deadline it cannot exceed.
Where that boundary stops is worth stating plainly rather than implying. An agent with a connected AWS account can obtain that account's credentials — it has to, to use them, and no arrangement of file permissions changes that for a process running as the agent's own user. What the boundary gives you is the shape of what it can obtain: temporary, scoped to the policy you wrote, in an account you control, and revocable by you without our involvement. Not "the agent cannot reach your cloud", but "what it reaches is what you granted, for an hour, and you can take it back".