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:

Start by reviewing the proposed integration points in policy.py/loader, along with repo-config, REPO_ONBOARDING.md, and SECURITY.md. Clarify the manifest format, verification behavior, Blueprint trust modes, and scope of the three proposed phases before implementation. Done means the RFC has an agreed design and an explicitly scoped implementation path.

Written by the indexing model from the issue text.