Security

Sign in with passkeys. Hand agents scoped tokens.

Heddle uses passkeys, device keys, and Biscuit capabilities so identity is portable, sessions can be narrowed, and every grant stays auditable. GitHub can help connect your account, but it does not become the root of who you are.

Self-sovereign auth

Your account starts with a key, not a password table.

Self-sovereign identity means Heddle verifies cryptographic proofs you control instead of treating a provider account or stored password as the permanent source of truth.

That makes the security model practical for agent work: you can add devices, scope sessions, delegate narrowly, and remove access without rebuilding your identity around a single OAuth provider.

01

Passkeys prove it is you.

Face ID, Touch ID, a hardware key, or your password manager signs a challenge for Heddle. We verify the public-key proof; there is no password for Heddle to store, leak, or reset.

02

Device keys make local work attributable.

After sign-in, this browser creates an Ed25519 device key. That key signs local actions and delegations, so work can be tied to a device you approved instead of only to a cookie.

03

Biscuit sessions can only narrow.

Heddle signs the root session at login. The client can append Biscuit attenuation blocks for a shorter time window, a specific repo, a limited operation, or a child agent. Verifiers check every block on every request.

04

GitHub connects context, not identity root.

OAuth can confirm an email, link a GitHub account, and unlock repo context. Heddle still mints its own subject, device key, and Biscuit session, so a provider is a link in the chain, not the chain itself.

Why it matters

Least privilege becomes the default path.

Users get passwordless sign-in and portable devices. Teams get auditable authority, explainable denials, and scoped agent sessions that expire or attenuate without granting the whole account.

01

Denial flow

Scope first. Then role, verified at the exact resource.

Token scope is checked ahead of role resolution. Every request resolves against the grants at the target resource.

Role denials name the exact path, the namespace or repo where the grant needs to live, so the fix location is never ambiguous.

02

Attribution inspection

Every state names its actor.

Each task-thread state carries principal, provider, model, and confidence as first-class fields. And, when the repo is configured to sign, an Ed25519 attestation on top. Naming is universal; cryptographic verification is opt-in for the chains that need it.

All of it sourced from env vars or explicit flags. Never parsed from a commit message. Never inferred from a Git email.

03

Grant diagnostic

Every denial names the principal, the target, and the role required.

Today: denials surface the subject, the exact resource path, and the role required at that scope. No opaque 403s, no hunting through logs to find which namespace needs a grant.

Next: held-role comparison and structured fix suggestions in the denial payload, so tools can remediate without a human parsing the error. Clearly labeled on the diagnostic below.

04

Token attenuation

Mint sub-agent tokens yourself. Authority only narrows.

Heddle's session token is a Biscuit capability: a chain of cryptographic blocks. The server signs the authority block once at login. Every narrowing after that is a block you append locally, with no round-trip.

Spinning up a sub-agent for a four-hour PR review, an overnight build, a one-shot scratch session: append a block that says this child can only do X for the next Y hours and hand the bytes over. The verifier runs every block's checks on every request, so a child can never widen what it inherited. Attribution isn't a string parsed from a commit message; it's the keypair signature on the chain that minted the state.

05

Redaction

When a secret slips in, scrub the bytes. Keep the receipt.

Heddle is content-addressed and immutable on purpose, but a leaked credential needs to come out. Redaction is the first-class primitive that reconciles both: an attributed, signed operation that declares a blob removed, swaps a stub into every materialized view, and leaves a tombstone any auditor can verify.

Two phases. heddle redact apply writes the tombstone: the state still resolves, but readers see the redaction notice in place of the secret. heddle redact purge apply, gated behind a required --force acknowledgement, removes the underlying bytes from local + canonical stores and appends a non-reversible oplog entry. The tombstone stays. The audit trail of the removal stays.

Authorization model

Every allow or deny names what decided it.

Passkey or provider link. Device key or session. Scope or role. The answer is always legible by construction.