Build1 publisher2 min readPublished
An SCP deny outranks the admin role a coding agent borrows in AWS member accounts
One SCP deny line blocked an AdministratorAccess session in a scratch AWS account, according to a dev.to guide to sandboxing coding agents. Its three gaps, the management account, service-linked roles and outside principals admitted by resource policies, set where an agent can run.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- The author's full sandbox SCP runs to seven statements, with 31 actions in the escalation class alone, and passed IAM Access Analyzer validation with zero findings.
- The sample assumes the default FullAWSAccess SCP stays attached, so it works as a deny-list and anything it does not deny can still be granted through IAM.
- For cross-account access, the author pairs SCPs with resource control policies, which constrain supported resources in member accounts even when the caller is external.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Agents need their own member account or OU, ideally without production data, because the SCP binds everything in the account and can break human and CI workflows in a shared one.
- exposure A resource type outside RCP support stays open to an outside principal that a resource policy admits, and the support list changes, so coverage has to be rechecked over time.
- cost Moving from FullAWSAccess to an allow-list SCP means maintaining an explicit allow at every level from the organization root to the account, on top of the IAM grant.
An SCP is a ceiling on what principals in a member account can do, and an IAM allow cannot override an explicit SCP deny [2]. The identity policy grants. A permissions boundary caps that grant without adding anything, and the SCP sits above both as a coarse guardrail [5]. The failure it is built for is ordinary: with enough engineers, someone reuses their admin role, a role with iam:*, or a production break-glass role for the agent [3]. "Policy review culture only gets you so far," the author wrote [4].
The sample's second statement is careful work. It denies iam:PutRolePolicy and iam:DeleteRolePolicy unless the caller's aws:PrincipalArn equals one role, AgentBreakGlassIncidentResponse, using an ArnNotEquals condition [6]. The exemption narrows the deny and grants nothing. The incident-response role still needs its own tightly scoped IAM and trust policies [7]. The first statement lists five escalation actions, among them iam:CreateAccessKey and iam:UpdateAssumeRolePolicy [6]. The other 26 in the escalation class appear only in the complete file [1]. The author wrote that the sample is "deliberately not advertised as complete CUD coverage" [9].
Service-linked roles are where a deny-list gets subtle [10]. Denying instance termination does not stop Auto Scaling from shrinking the fleet through its service-linked role [11]. Auto Scaling does not consult your deny-list before it scales in [10]. Denying object deletion does not stop a lifecycle rule from expiring objects [12]. The author's rule is to deny the outcome, not only the obvious API [11]. In my view that puts the configuration call, such as writing a lifecycle rule, on the deny-list next to the delete it schedules [12].
"Keep agents in member accounts," the author wrote [13]. The rollout order is to block the highest-blast-radius actions first, watch what legitimate workflows trip over, then widen deliberately [20]. I think the blunt version is the right tradeoff for coding agents, under the condition the author sets. When the sandbox holds nothing that matters, the deny-list can stay blunt instead of carving exceptions forever [21].
What to watch
- AWS's RCP supported-service list: each resource type added narrows the route by which an outside principal admitted through a resource policy can reach an agent's account.
- Whether the full agent-sandbox-scp.json denies the configuration calls behind indirect deletion, such as S3 lifecycle rules and versioning changes, alongside its 31 escalation actions.