What the protocol guarantees by construction#
- Fail closed. v0.2 specifies that an unknown, missing, ambiguous or unavailable input produces
DENY, neverALLOW. The engine implements every check in a fixed order and the first failure is the reason. - Nothing to trust but signatures. A Grant is signed by the company with a key in its DID document; a Proof is signed by the agent and bound to one recipient, one action and one moment; the receipt is signed by Delegus. Every link is a signature or a domain proof.
- Receipts are evidence. Each receipt pins the hashes of the Grant, the request, the company's DID document and the revocation list as they stood, and the profile applied. Anyone holding a receipt can re-run the protocol checks against those preserved artifacts without calling Delegus (spec §6, §8).
- Revocation is read-after-write.
/revokereturns success only once every later/verify, on any node, will see it (spec §7). - The verify path is narrow.
/verifytouches only the database and the cache. No DID resolution, DNS lookup or third-party call happens while a decision is being made (spec §5.5).
How the service is run#
| Area | Control |
|---|---|
| Signing keys | Ed25519 keys in AWS KMS, hardware-backed, non-exportable. Receipts and status lists are signed inside KMS; private key material never enters a process. Rotation adds a new key id; keys are never deleted, and an organization policy makes production keys undeletable even by an account administrator. |
| Evidence | Every artifact a receipt references is stored by hash in S3 with Object Lock. The production bucket has Object Lock in compliance mode with a seven-year default retention, which cannot be shortened once written. The bucket is private, TLS-only and encrypted with its own rotating key. |
| Data in transit | TLS everywhere: to the API, to the database and to the cache. Certificates are issued by AWS Certificate Manager. |
| Secrets | The admin token is generated at deploy time, stored in AWS Secrets Manager, and never enters infrastructure state or logs. Database credentials are AWS-managed and rotated. API keys are shown once at issue, stored hashed, and can be rotated and revoked by their holder; a revoked key stops working immediately. |
| Deployment | Images are built and deployed through GitHub with a short-lived OIDC role scoped to one repository and environment; the role can push an image and roll the service, nothing else. If a new release fails to start or fails its health checks, the service automatically rolls back to the last working version. |
| Edge | AWS WAF in front of the load balancer with per-IP rate limiting and managed rule groups. The API enforces its own limits per key and per IP and answers 429 with Retry-After. |
| Audit trail | An organization-wide CloudTrail records every control-plane action. The API keeps an append-only audit log of onboarding, key, agent, Grant and revocation actions with the actor, target and request id, readable by administrators in full and by each company or relying party for its own actions (GET /audit). Every request carries a request id, returned to the caller. Receipts themselves are an immutable, signed record of every authorization decision. |
| Alerting | CloudWatch alarms on error rate, unhealthy targets, task count and datastore health, delivered to the operations mailbox (email today; no paging service yet). Production also runs AWS Config, Security Hub (AWS Foundational Security Best Practices) and GuardDuty; high and critical findings and any tamper attempt on a signing key or the evidence bucket alert the operations topic. Service health for development and production is on a public status page. |
| Isolation | Development and production are separate AWS accounts under one organization with guardrail policies. Development identifiers use did:web:dev.delegus.ai; nothing issued there is a production artifact. |
The specification's threat model (§13) is mapped threat by threat to the check, the code path and the test that addresses it in the threat model mapping, which is also the starting document for the penetration test.
Coming soon#
- SOC 2 report
- Independent penetration test
- Published uptime and SLA
- More regions
Reporting a vulnerability#
Write to hello@delegus.ai with the subject "Security", saying what you found and how to reproduce it. We acknowledge within two business days. Please test in the free sandbox in your account, not against other customers' data.