aws-samples / aws-samples/sample-autonomous-cloud-coding-agents
(security): execution-layer hardening below agent tool policy
- Dominant language
- TypeScript
- Stars
- 143
- Forks
- 46
- Avg merge
- 3d 9h
- Merged PRs (30d)
- 20
Description
## 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
Contributor guide
Research direction
Start with SECURITY.md and the related docs/design/SECURITY.md, docs/design/CEDAR_HITL_GATES.md, and docs/design/COMPUTE.md to map the existing boundary and controls. Then trace the CDK/infrastructure entry points for the agent image, DNS Firewall, Blueprint options, and enforce-mode checks. Done means the layered design is documented, the requested controls and opt-out path exist, and smoke checks cover disallowed commands and network destinations without regressing reference repositories.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, typescript
- Domain
- cloud, devops, infrastructure, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100