Autonomous investigation. Controlled execution.

• Provider tokens are encrypted at rest with an application-level key.
• Tokens never reach the browser and never appear in a URL.
• Tokens are never written to logs; errors redact credential-bearing strings before they're ever thrown.
• Only the scopes a repository connection actually needs are requested and stored.

• Repository access is scoped to what you explicitly connect, not your whole account.
• Access is verified before a project is activated.
• Repository content is treated as untrusted input, never executed outside an isolated environment.

• Repository operations run in ephemeral, time- and resource-limited workers.
• No production credentials are available inside a diagnosis or fix run.
• Every command NinjaClaw executes is captured in structured logs.

• Secrets and personal data are scrubbed before anything reaches a model prompt.
• Model output never directly triggers a deployment — every proposed change passes through deterministic policy checks first.
• Every model request and response is recorded, with model and prompt version identifiers, for the audit trail.

CI job log output — the one place raw, third-party-influenced text already enters a live incident — is read only by a separate, zero-tool-access model restricted to a schema-validated structured output. The privileged planner never sees that raw text. Verified against a real, live prompt injection planted inside a CI log: the reader extracted only genuine technical facts.

Every piece of context a diagnosis's planner sees — the extracted CI log summary, INTENT.md, each source file, and the incident's own metadata — is SHA-256 hashed and stored with the fix, so a later check can catch anything substituted after the fact. A tamper-evidence record, not a filter, shown in full on each incident's detail page.

Every proposal, policy decision, approval, and execution is signed (Ed25519) and hash-linked to the one before it — inserting, deleting, reordering, or editing an entry breaks a signature, not just a database reference. Signing keys are split across two separate credentials, not one shared secret: the agent process is never configured with the human-approver or executor key, so it cannot produce a valid approval signature today. That boundary is currently enforced by which secret is deployed where, not yet by an external authorization system (a KMS grant an agent's identity is denied) — that stronger guarantee is on our roadmap, not silently assumed. Includes the diff a human approves being independently recomputed from the provider's live pull-request API at merge time and hard-blocked on mismatch. Re-verified fresh every time an incident's ledger is viewed, not cached. This makes the chain tamper-evident against modification — proving it was never wholesale replaced by someone who also holds the keys requires external anchoring, which isn't built yet.

The agent process runs non-root and read-only outside its workspace, with an allowlist of the project's own build/test toolchain and network destinations. Any violation blocks the action, logs it to the audit ledger, and can halt the task pending explicit human release.