(security): execution-layer hardening below agent tool policy

## Component

CDK / infrastructure

## Describe the feature

Strengthen security controls at the compute and OS layer so that policy enforcement does not rely solely on agent-visible tool gates (Cedar HITL, bash allowlists, prompt guardrails). The platform should assume a motivated or compromised agent may attempt to invoke binaries, exfiltrate data, or bypass userspace restrictions through shell indirection, renamed executables, or unexpected network paths.

Deliver a layered model—minimal base image, tightened default command surface, enforce-mode network controls, and documented extension points for stricter profiles—aligned with ABCA's "security boundary is the sandbox" principle in `SECURITY.md`.

## Use case

I'm always frustrated when security reviewers ask what stops an agent from running arbitrary commands after a prompt injection or tool-policy miss. Cedar governs declared tool calls well, but bash and subprocess paths can still reach binaries present in the image. Operators need a credible story for high-autonomy deployments: defense in depth below the LLM, not only in front of it.

## Proposed solution

1. **Minimal agent image profile** — Define a hardened default image variant: fewer preinstalled utilities, documented allowlist of packages, separate "extended" profile for repos that opt into more tools via Blueprint.
2. **Bash and subprocess tightening** — Review and narrow default bash allowlist; block or gate high-risk patterns (raw network fetch binaries, credential harvesters) with clear Cedar + runtime alignment.
3. **Network enforcement path** — Document and implement operator toggle for DNS Firewall enforce mode (today observation mode is common); tie egress allowlists to Blueprint with fail-closed defaults for sensitive repos.
4. **Behavioral circuit breaker (coordination)** — Integrate with roadmap per-session limits (tool rate, file churn, cost) that terminate sessions and revoke short-lived credentials on trip.
5. **Threat model documentation** — Add a `SECURITY.md` section on execution-layer threats (unexpected code execution, exfiltration) and which controls address each layer; reference OWASP agentic application risks where applicable.
6. **Future extension point** — Design note for optional syscall- or kernel-level enforcement on ECS/EC2 backends without committing to a specific LSM product in v1.

## Acceptance criteria

- [ ] Hardened default image (or profile) is documented and available; existing repos can opt out via Blueprint during migration.
- [ ] DNS Firewall (or equivalent egress control) supports enforce mode per repo with operator runbook.
- [ ] Security design doc describes layered controls: MicroVM isolation, IAM session scoping, Cedar, network, image minimization—and known residual risks.
- [ ] Tests or smoke checks verify that representative disallowed commands/network destinations fail in enforce mode.
- [ ] No regression to task success rate on reference repos using the default profile.

## Other information

- Related roadmap: **Behavioral circuit breaker**, **Tool capability tiers**, **Zero Trust control review**, DNS Firewall enforcement.
- Related design: `docs/design/SECURITY.md`, `docs/design/CEDAR_HITL_GATES.md`, `docs/design/COMPUTE.md`.
- Cedar remains the right layer for tool-call governance; this feature closes the gap between tool policy and OS/network reality.
- Alternatives considered: Cedar-only expansion (insufficient for bash); blocking all bash (too restrictive for coding tasks).

## Acknowledgements

- [ ] I may be able to implement this feature
- [ ] This might be a breaking change

Inizia da SECURITY.md e dai documenti correlati docs/design/SECURITY.md, docs/design/CEDAR_HITL_GATES.md e docs/design/COMPUTE.md per mappare il confine e i controlli esistenti. Poi segui i punti di ingresso CDK/infrastruttura per l’immagine dell’agente, DNS Firewall, le opzioni di Blueprint e i controlli della modalità enforce. Il lavoro è completato quando il design a livelli è documentato, esistono i controlli richiesti e un percorso di opt-out, e gli smoke check coprono i comandi e le destinazioni di rete non consentiti senza introdurre regressioni nei repository di riferimento.

Scritto dal modello di indicizzazione a partire dal testo della issue.