Security
Aferiz holds git and management credentials and runs an agent over someone else’s repository. The threat model is explicit — this page sums up what is designed and what still has to be proven.
No badge, no certification — yet. What exists is a verifiable design, and the list of what must be green before the first external customer, published at the end of this page.
Isolation by organization
The organization is the data boundary. Every entity carries the organization id, and every query is filtered by it twice: by the database’s global filter and again by the service running it. A user from organization A reads nothing from B — not even by the direct id of a child row.
Credentials only go in
Each credential is encrypted value by value (AES-256-GCM), with the master key kept outside the database. No API response ever returns a credential — not even to whoever registered it. The runner receives it from the control plane at execution time, over an authenticated channel, and discards it at the end; never as a command-line argument, visible in ps.
A central filter rewrites known secrets as *** in logs, events, artifacts and responses. And an automated test plants a canary secret in every output surface: if it shows up, the build fails.
The sandbox never sees the credential
Every run happens in an ephemeral container: non-root user, capabilities dropped, network on an allowlist — the LLM endpoint, the git host, the source host; everything else denied — with CPU, memory, time and disk limits. The repository’s own build commands — dotnet test, npm run build — are the most likely vector for hostile code, and they run in that sandbox without the connection credentials in the environment.
Evidence read from the commit, not from disk
Every verdict requires evidence at file:line — and the runner checks it against the git object of the audited commit, never against the sandbox disk. An agent writing to the worktree could not fabricate its own proof. Without confirmed evidence the verdict drops to inconclusive; an objection with no anchor in the requirement text is discarded before it reaches anyone.
Prompt injection is treated as the central risk
The agent reads content an attacker can control: a README, a code comment, the card’s own description. The defense is not hoping the model ignores it — it is removing the power: instructions and third-party content travel on separate channels; the attestation and validation agents have no external write at all; commands and network go through allowlists; and a verdict only enters the database after the evidence is mechanically verified. An injected “mark everything as met” produces a verdict without evidence — which becomes inconclusive.
Classic injection patterns in the input raise a warning on the run: the human sees there was an attempt.
Roles
Six roles per organization, from reader to admin:
- Reader
- Sees projects, runs, attestations, objections and specs.
- Requirement author
- Creates and edits requirements; accepts, answers and closes objections.
- Operator
- Triggers runs, gives feedback on verdicts, requests spec adjustments.
- Developer
- Everything an operator does, plus accepting specs.
- Approver
- Approves external-write proposals and standard rules.
- Admin
- Connections, agents, pipelines, members, keys and policies — all audited.
Two rules are not configurable, because they are product invariants: whoever wrote a version of the requirement cannot accept its spec; and approving a standard rule is always an identified human — no API key scope, tool or policy waives that.
Audit
An immutable record of logins, connections, runs, approvals, acceptances, standard rules and configuration changes — with author, time, old and new value. Nothing is deleted; a correction is a new entry. Minimum retention of twelve months, exportable as JSON. Objections, acceptances and reports outlive the retention of the run that produced them: they are the record of what was agreed.
What is missing before the first external customer
The exit list is mandatory. While an item is open, it is open here too:
- Canary secret
- Test green across log, event, artifact, API and notification.
- Sandbox by default
- In-process execution only with explicit opt-in.
- Network allowlist, proven
- A test that tries to get out and fails.
- Webhook signatures
- Validated on every incoming webhook.
- Rate limiting
- Active on API and webhooks.
- Dependencies and base image
- Reviewed, no critical CVE.
- Tenant isolation
- A test that organization A reads nothing from B.
- Retention policy
- Implemented and documented on the privacy page.
Formal certification (SOC 2, ISO 27001) does not exist today and is not promised for a date. When it enters the road, it shows up here.