The IAM Gap: Securing Claude Code and Agentic Workflows
We've spent years locking down service accounts and human identities, but Anthropic's Claude Code is throwing a wrench in the works. It’s not just a chatbot; it’s an autonomous agent with shell access. The latest report on how Ceros is tackling this highlights a major blind spot: we have visibility on users, but not on the agents they unleash.
These agents can read files, execute shell commands, and call external APIs. If an LLM decides to git push --force or modify a firewall rule based on a hallucination, our standard IAM controls might be too slow to react.
I'm currently trying to baseline behavior for agentic tools. Since these agents often operate under a user's context or a generic service account, detecting anomalies is tough. I've started querying for high-impact commands initiated by processes associated with known AI binaries.
Here is a basic KQL query I'm testing to flag when Claude Code attempts infrastructure changes:
let AnthropicProcesses = dynamic(["claude-code", "anthropic-agent"]);
DeviceProcessEvents
| where InitiatingProcessFileName in (AnthropicProcesses)
or ProcessCommandLine contains "anthropic"
| where ProcessCommandLine has_any ("kubectl apply", "terraform destroy", "ssh", "sudo")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessAccountSid
| order by Timestamp desc
Are you guys allowing AI agents direct shell access in your environments, or are you strictly keeping them within API boundaries? If you're using tools like Ceros for visibility, has it actually helped you catch something risky?
We're seeing the same issue with Cursor and Copilot. The query is a good start, but we've had to implement eBPF policies to restrict the syscalls these agents can make. We don't allow them to touch /etc/shadow or modify systemd services directly. It creates some friction for the devs, but it beats explaining a data breach to the CISO.
Great initiative on the KQL. We actually banned shell execution entirely for our coding agents. They run in a sandboxed container with no network access unless explicitly proxied through a custom gateway we built. It forces the agents to output the script to a file instead of running it, which a human then has to audit and execute. Slower, but safer.
From a pentester's perspective, these agents are a dream for lateral movement. If I can inject a prompt into a repo the agent is scanning, I can trick it into running my recon commands for me under legitimate credentials. The 'visibility' problem is real because the SIEM just sees a trusted engineer running python scripts.
Great insights on the runtime restrictions. To bridge that IAM gap, we’re mapping agent sessions to ephemeral IAM roles with OIDC, rather than inheriting the developer’s full context. This enforces least privilege at the identity layer.
We use a validating admission webhook to inject these constraints automatically:
rules:
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get"]
Combined with the eBPF limits, this ensures the agent can only 'see' and 'touch' what is absolutely necessary for the specific task, reducing the impact of a compromised prompt.
Mapping sessions to ephemeral roles is a solid foundation. We’re also adding a 'human-in-the-loop' checkpoint for destructive commands using a shell wrapper. If the agent attempts a rm -rf or modifies firewall rules, it halts and fires a webhook requiring manual approval. It’s a low-tech friction layer that prevents high-velocity errors.
if [[ "$cmd" =~ (rm -rf|iptables) ]]; then
curl -X POST https://approval-gate/check -d "$cmd"
fi
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access