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:

Commencez par examiner les points d’intégration proposés dans policy.py/loader, ainsi que repo-config, REPO_ONBOARDING.md et SECURITY.md. Clarifiez le format du manifeste, le comportement de la vérification, les modes de confiance de Blueprint et la portée des trois phases proposées avant l’implémentation. Le travail est considéré comme terminé lorsque le RFC dispose d’une conception approuvée et d’un chemin d’implémentation dont le périmètre est explicitement défini.