Home / Blog / Claude Code Security: What You're Missing
Claude Code security RBAC permissions

Claude Code Security: What You're Missing

April 26, 2026 · 7 min read

Claude Code ships with a permission system. You’ve probably already disabled it. The --dangerously-skip-permissions flag exists because the built-in prompts interrupt agent flow to the point where autonomous operation becomes impractical. So teams skip them. And then they have an agent with no security controls running against their infrastructure.

That flag name isn’t accidental. Anthropic is telling you this is dangerous. But they didn’t ship an alternative that works for production. So here you are.

What —dangerously-skip-permissions Actually Means

Claude Code’s default permission model is interactive — the agent asks for confirmation before executing commands, writing files, or calling tools. This works when you’re watching. It doesn’t work when the agent runs autonomously.

When you skip permissions, every tool call is auto-approved. Every shell command executes. Every file write goes through. The agent has exactly the same access as the user or service account that launched it.

If that user has AWS admin credentials, the agent has AWS admin credentials. If their SSH key can push to production branches, the agent can push to production branches. If there’s a database connection string in the environment, the agent can query or modify the database.

What MCP Servers Expose

Model Context Protocol servers extend Claude Code’s capabilities. A GitHub MCP server lets the agent create pull requests. A database MCP server lets it run queries. An AWS MCP server lets it manage cloud resources.

Each MCP server you add expands the agent’s attack surface. Not because the servers are malicious — they’re doing exactly what they’re designed to do. The problem is there’s no permission layer between Claude Code and the MCP server. If the server can do it, the agent can do it.

Consider a PostgreSQL MCP server. You add it so the agent can check schema definitions. But the server doesn’t distinguish between SELECT on schema tables and DROP TABLE on your production data. It’s a database connection. Everything the connection can do, the agent can do.

“Use a read-only database user” is correct, and also insufficient. You need that same least-privilege thinking applied to every MCP server, environment variable, and tool the agent has access to.

The AWS Credential Problem

The most dangerous Claude Code configuration is also the most common: AWS admin credentials, because the developer who set it up uses that profile for daily work.

Real scenario: The agent deploys a Lambda function. It has AdministratorAccess. During deployment, it decides the function needs an SQS queue and DynamoDB table — so it creates them. It decides the function needs internet access — so it modifies the VPC security group. Every action is logged in CloudTrail, but nobody reviews CloudTrail in real time.

Two weeks later, the security team finds an overly permissive security group, an unencrypted DynamoDB table, and an SQS queue with no dead letter queue. Tracing back to the agent session requires correlating timestamps across multiple AWS services.

What proper AWS access looks like:

  • Temporary credentials from STS AssumeRole, not long-lived access keys
  • IAM policies scoped to specific resources (this S3 bucket, this Lambda function)
  • Service-level restrictions (can read EC2, cannot modify security groups)
  • Session duration limits (credentials expire after 1 hour, not 12)
  • Session tags that identify the agent, developer, and project

What a Proper Security Layer Looks Like

The security model you need for Claude Code has four components.

Identity: Every session attributed to a specific human and purpose. Session ID appears in every log entry. Any action traceable back to who launched it and why.

Policy: Before any operation executes, it’s checked against a policy engine. The policy defines what this session is allowed to do — which repos, which AWS actions, which MCP tools. Defined by the team, not the individual developer.

Audit: Every operation logged in an immutable, structured format — not just “agent called AWS API” but which session, which developer, what operation, what parameters, what result.

Control: You can stop any session at any time, modify policies without restarting agents, set cost limits, and require human approval for specific operations.

The Uncomfortable Truth

Claude Code’s security model assumes a human is watching. --dangerously-skip-permissions is an escape hatch for development, not a production configuration. But Anthropic hasn’t shipped a production-grade alternative, so the ecosystem is building one.

The gap between “Claude Code with no security controls” and “Claude Code with proper production security” is where a control plane fits. A gateway layer that sits between the agent and your infrastructure, enforcing policies, logging actions, and providing operational control.

Without a security layer, the answer to every question about agent permissions is “the agent can do whatever it wants.” That’s not security. That’s hope.

// get-started

Put this into practice with Sentrely

Everything covered in this article is built into Sentrely's managed control plane. Get early access and have it running against your Claude agents in minutes.