aws-samples / aws-samples/sample-autonomous-cloud-coding-agents

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

Open
#390 0 comments 0 reactions 0 assignees View on GitHub
enhancement security
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.