AI coding assistants have moved well past autocomplete — many now execute shell commands, run deployments, and query cloud infrastructure directly as part of an agentic workflow. That capability shift changes the security question from "what can this tool suggest" to "what can this tool actually do to production," and a lot of teams are granting that access with the same broad credentials a human engineer would use, rather than a permission model scoped to what an autonomous or semi-autonomous agent should actually be allowed to touch.
Why Human-Scoped IAM Doesn't Transfer Cleanly to Agents
A senior engineer's IAM permissions are typically broad because human judgment fills the gap between "technically possible" and "actually a good idea" — a human won't run terraform destroy against production without a very good reason, even with the permission to do so. An AI coding assistant, especially one operating semi-autonomously across multiple steps, doesn't have that same judgment backstop by default, which means the permission boundary itself needs to do more of the safety work than it does for a human user with the same nominal access level.
The Scoped Permission Model We Build
Rather than granting an AI assistant the same IAM role as the engineer directing it, we build a distinct, narrower role specific to the assistant's actual task scope:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["lambda:GetFunction", "lambda:UpdateFunctionCode"],
"Resource": "arn:aws:lambda:*:*:function:staging-*",
"Condition": {
"StringEquals": {"aws:RequestTag/environment": "staging"}
}
},
{
"Effect": "Deny",
"Action": ["lambda:DeleteFunction", "iam:*", "rds:Delete*"],
"Resource": "*"
}
]
}
Three principles drive the design: scope by resource tag or naming convention (staging vs. production, never both under the same role), explicit deny statements for destructive or identity-modifying actions regardless of what the allow statements might otherwise permit, and short-lived credentials issued per session rather than a long-lived key attached to the agent's runtime.
Human-in-the-Loop for Production-Reaching Actions
For actions that touch production — not just staging or a sandboxed environment — the pattern we recommend isn't full autonomy, it's scoped autonomy with an explicit approval gate: the agent can propose and stage a change (a Terraform plan, a deployment diff), but the actual apply/execute step requires a human approval action, logged as part of the audit trail. This preserves the speed benefit of AI-assisted operations for the exploratory and preparation work while keeping a human decision point at the moment of actual production impact.
Capability Tokens Over Standing Roles
For agents that call multiple internal APIs or tools, a capability-token model — short-lived, narrowly-scoped tokens issued per task rather than a standing role the agent always holds — limits the blast radius of a compromised or misbehaving agent session to whatever that specific token permits, rather than whatever the agent's persistent identity could theoretically do. This mirrors the workload identity federation principle applied to CI/CD: minimize what's standing, maximize what's short-lived and task-scoped.
Logging for Audit and Incident Response
Every action an AI coding assistant takes against production or staging infrastructure should generate an audit log entry distinguishable from a human-initiated action of the same type — not because AI-initiated actions are inherently suspect, but because incident response and SOC 2 access evidence both depend on being able to answer "was this action taken by a person or an agent, under what session, with what approval" without ambiguity.
Where This Fits Into SOC 2 Evidence
As AI coding assistants become a normal part of engineering workflows, auditors are increasingly asking how organizations control and evidence their access — this is a natural extension of existing access review and least-privilege evidence, applied to a newer class of identity. Building the scoped permission model and audit logging now, rather than retrofitting it after an incident or an audit question, is the more defensible position.
This permission model builds directly on the approach in AI agent least privilege, part of our security automation capability.
Discuss securing your AI agent build: 907-841-8407 or contact@rutagon.com.
Discuss securing your AI agent build →
Frequently Asked Questions
Should AI coding assistants ever have direct production write access?
It's possible with the right guardrails (scoped roles, explicit denies on destructive actions, human approval gates for production-impacting steps), but many teams are better served starting with staging-only autonomous access and a human-approved promotion path to production.
How is a capability token different from a standard IAM role?
A capability token is issued per task with a narrow, explicit scope and short lifetime, rather than being a persistent identity the agent always holds — it limits what any single compromised or errant session could do, independent of what the agent's broader identity might otherwise be trusted with.
Does this permission model slow down AI-assisted development significantly?
For staging and development environments, minimally — the scoping mainly affects production-reaching and destructive actions, where added friction is the intended tradeoff for reduced blast radius.
How do you distinguish AI-agent actions from human actions in audit logs?
By tagging the session or credential used at authentication time with an identity type (human vs. agent) and session/task ID, then carrying that tag through to every logged action, so post-hoc audit queries can filter cleanly by actor type.
Does this apply to third-party AI coding tools, or only custom-built agents?
It applies to both — third-party tools that request cloud or infrastructure access should be evaluated against the same scoped-permission and audit-logging expectations as a custom-built agent, since the underlying risk (an autonomous actor with infrastructure access) is the same regardless of who built the tool.