RFC: Signed attestation for repo-local agent instruction files

## Primary area

** Cross-cutting / multiple

## Related issue or feature request

_Complements roadmap **MCP supply-chain controls** and **Untrusted hydration content boundaries**._

## Summary

Introduce optional **cryptographic attestation** for trusted instruction sources (`AGENTS.md`, `.claude/rules/`, workflow prompt fragments) so the agent runtime loads only files signed by an approved publisher key. Unsigned or tampered files are rejected or downgraded to untrusted reference text.

## Use case and motivation

Prompt injection via markdown instruction files is structural: any file the agent reads may contain adversarial directives. Policy-at-the-LLM-layer is bypassable. High-trust repos need assurance that harness content was not substituted on a feature branch or via compromised commit access.

## Proposal

### Trust model

- Operator publishes org signing key (KMS or offline) referenced in Blueprint.
- Trusted paths list per repo; each file has sidecar signature `path.sig` or embedded manifest in `.abca/trust-manifest.json`.
- Agent bootstrap verifies signature before merging rules into context; failures fail-closed for high-trust mode, warn-only for standard mode.

### UX before / after

**Before:** Agent loads any committed markdown rules.

**After:** Blueprint `instruction_trust_mode: strict|warn|off`; strict blocks task start on verification failure.

### Phases

1. Manifest format + verification library in agent (`policy.py` / loader).
2. CLI `bgagent trust sign` for local dev ergonomics.
3. CI check optional in contributor guide.

## Out of scope

- Signing every source code file.
- Replacing Cedar tool-call policy.
- Kernel-level enforcement (see runtime telemetry RFC).

## Potential challenges

- Key rotation and manifest updates on forked PRs from external contributors.
- UX friction for small teams—must default to `off`.
- Parity between Python agent and any future TypeScript dry-run path.

## Dependencies and integrations

- `repo-config`, `REPO_ONBOARDING.md`, `SECURITY.md`
- KMS for managed keys in AWS deployments

## Alternative solutions

- **Git commit signature verification only** — does not protect against malicious maintainer commits on branch.
- **Hash allowlist in Blueprint** — brittle without signing pipeline.

---

**Note:** Non-triaged RFCs may not get timely review. PRs on non-triaged issues might not be accepted.

* RFC PR:
* Approved by:
* Reviewed by:

Beginne damit, die vorgeschlagenen Integrationspunkte in policy.py/loader sowie repo-config, REPO_ONBOARDING.md und SECURITY.md zu überprüfen. Kläre vor der Implementierung das Manifestformat, das Verifizierungsverhalten, die Blueprint-Vertrauensmodi und den Umfang der drei vorgeschlagenen Phasen. Als abgeschlossen gilt die Aufgabe, wenn der RFC ein abgestimmtes Design und einen ausdrücklich abgegrenzten Implementierungspfad enthält.

Vom Indexierungsmodell aus dem Issue-Text verfasst.