$ man how-to/team-security-cloud-guardrails

Securityadvanced

Security Guardrails for Cloud Teams

Branch protection, secrets management, and access control for teams deploying agents


The Security Architecture

AI agents with access to production systems need guardrails. Not paranoid restrictions that make them useless, but practical boundaries that prevent catastrophic mistakes. The architecture has three layers. First, what runs locally vs what runs in the cloud. Sensitive operations - API key management, database migrations, secrets rotation - stay on local machines where you have physical control. Agent workloads that process data and generate output run in the cloud where they scale. Second, repo-level protections. Branch protection rules prevent agents from pushing directly to main. Required reviews ensure a human sees every change before it hits production. Pre-push hooks scan for secrets, API keys, and partner-identifiable data before anything leaves your machine. Third, runtime guardrails in Claude Code itself. CLAUDE.md rules define what the agent can and cannot do. The agent respects these rules because they are loaded into context at session start.
PATTERN

Local vs Cloud for Sensitive Ops

Keep local: .env files, API key rotation, database credentials, SSH keys, partner data, anything that would be catastrophic if leaked. Push to cloud: agent code, workflow definitions, processed (anonymized) data, generated content, deployment artifacts. The rule: if the data exists in one place (your machine) and leaking it means calling every client, keep it local. If the data is generated or derived and losing it means re-running a script, it can go to the cloud. For agents on Railway or similar: pass secrets as environment variables in the hosting dashboard. Never commit them. Never log them. Never include them in error messages. The agent code references process.env.API_KEY, not the actual key.
CODE

Branch Protection and Review

GitHub branch protection settings for teams with AI agents: 1. Require pull request reviews before merging to main. Even if the agent wrote the code, a human reviews it. 2. Require status checks to pass. Run your test suite and security scan before any merge. 3. Require branches to be up to date before merging. No stale branch merges that create conflicts. 4. Restrict who can push to main. Agents push to feature branches. Humans merge to main. Pre-push hooks add another layer. The Husky pre-push hook scans every commit for patterns that should never be pushed: API keys (strings matching key patterns), partner names (from a local blocklist), .env file contents, and large binary files. The push fails if any pattern matches.
PRO TIP

Claude Code as a Security Layer

Claude Code itself enforces security through CLAUDE.md rules. This is underappreciated. Add rules like: "Never commit .env files. Never log API keys. Never include partner names in commit messages. Always check .gitignore before adding files. Run the pre-push blocklist scan before every push." The agent follows these rules because they are in its context. It becomes a security-conscious collaborator. When you tell it to push code, it runs the scan first. When you tell it to add a file, it checks .gitignore first. When you tell it to log debug info, it redacts sensitive values. This is not foolproof. It is a layer in a defense-in-depth strategy. Combined with branch protection, pre-push hooks, and secret management, it covers the common failure modes where teams accidentally leak credentials or push sensitive data.

knowledge guide
See "Claude" in Knowledge See "Agent" in Knowledge

related guides
AI Security Myths DebunkedConstraints and Context EnginesEnvironment Files Explained
how-to wikiknowledge guide
ShawnOS.ai|theGTMOS.ai|theContentOS.ai
built with Next.js · Tailwind · Claude · Remotion