TL;DR
- If you are searching for "secure Claude Code", the core issue is not the model. It is tool authority: shell commands, file access, web calls, and MCP tools.
- Claude Code already has the right integration point: PreToolUse hooks.
- APort adds a passport-backed authorization check at that boundary, so risky actions are allowed or denied before they run.
- The fast path is still one command.
The 60-second secure setup
For a local developer machine, run:
npx @aporthq/aport-agent-guardrails claude-code
If your team prefers install URLs, the same flow is available from the main APort domain:
curl -fsSL https://aport.io/install.sh | bash -s -- claude-code
The -- in bash -s -- claude-code is the standard Bash argument separator.
It passes claude-code to the installer. It is not an APort flag.
The installer asks for a claim email, then configures:
- An agent passport for the Claude Code instance.
- A narrow setup API key for hosted verification.
- A Claude Code guardrail install using
@aporthq/aport-agent-guardrails.
The install command wires the passport ID and setup key into the guardrail config, so the developer does not need to copy values between the dashboard and terminal.
Why Claude Code security needs more than prompts
Claude Code can read files, edit code, run shell commands, call MCP tools, and push changes through a normal developer workflow. Those actions need a deterministic authorization gate before execution.
If you searched for "Claude Code hack", "Claude Code prompt injection", "Claude
Code delete database", or "secure Claude Code", you are probably looking for
the same control: a way to stop the agent before a risky tool call runs.
Project instructions, CLAUDE.md, and permission settings help guide behavior.
They are useful. They are not the same thing as authorization.
Anthropic's own docs describe Claude Code hooks as lifecycle events around tool
use, including PreToolUse. That is the right place for policy because the hook
receives the proposed action before the action executes. If a command tries to
read .env, run a destructive shell command, or call an MCP tool that is not in
scope, the policy decision can return DENY before the side effect happens.
This distinction matters because the major agent risks in 2026 are action risks:
- Prompt injection: malicious instructions enter through files, docs, web pages, issues, or tool output.
- Sensitive information disclosure: an agent reads or emits secrets, tokens,
.envfiles,.awscredentials, or SSH material. - Tool misuse: an agent uses a valid tool in the wrong context, with the wrong target, or at the wrong privilege level.
- Excessive agency: an assistant has more authority than the task requires.
Those map directly to the categories in the OWASP Top 10 for LLM Applications and the newer OWASP work on agentic AI security. The common thread is that a chat response is no longer the only output. The output is an action.
What APort checks for Claude Code
APort turns each Claude Code tool request into a policy question:
| Claude Code action | APort policy area | Example deny |
|---|---|---|
Bash command
|
system.command.execute.v1
|
Block rm -rf, production database CLIs, unsafe curl pipes, or commands outside allowlists
|
Read, Grep, Glob, LS
|
data.file.read.v1
|
Block .env, .aws/, .ssh/*, private keys, and credential files unless explicitly allowed
|
Write, Edit, MultiEdit
|
data.file.write.v1
|
Block writes outside the repo, oversized changes, generated secret files, or protected paths |
WebFetch, WebSearch
|
web.fetch.v1 and web.search
|
Limit network access to approved domains or block private IP ranges |
| MCP tools |
mcp.tool.execute.v1
|
Detect real mcp__server__tool names and block unapproved servers or tools
|
The point is not to make Claude Code useless. The point is to make the safe path
fast: allow normal development work, deny dangerous actions, and log both.
What gets audited
Each hosted verification request creates a decision record with the passport ID, policy ID, allow or deny result, reasons, timestamp, and request context. That gives teams a timeline of what the agent attempted, not just the final code diff.
For Claude Code, the most useful audit events are usually:
- Shell commands such as
npm test,git push, or destructive file operations. - File reads and writes, especially around sensitive paths.
- MCP tool calls, including the server and tool name where available.
- Web requests made during implementation or debugging.
This is why APort uses a passport model. A passport gives the agent a stable
identity, scoped capabilities, limits, and a kill switch. A decision record then
answers the question security teams actually ask after an incident:
What did the agent try to do, what was allowed, what was denied, and under which policy?
Why "Claude Code deleted a database" is the wrong lesson
Recent reporting on AI coding agent incidents, including the widely discussed
PocketOS/Cursor database deletion report, has made one lesson obvious: the
failure is rarely that the model can type SQL. The failure is that an agent has
valid credentials and enough authority to make an irreversible call.
That is an authorization problem.
The right response is not "never let developers use Claude Code." Developers
will use tools that make them faster. The right response is:
- keep production credentials out of normal coding-agent contexts;
- make destructive commands require explicit policy, not model confidence;
- block sensitive file reads by default;
- scope MCP servers and tools by passport;
- log decisions centrally;
- keep backups and branch protection outside the agent's control.
APort covers the pre-action authorization and audit layer. It should sit beside
normal engineering controls: least-privilege cloud credentials, branch
protection, secret scanning, backup isolation, and human review for production
changes.
The research direction is moving the same way. A 2026 preprint, Are
AI-assisted Development Tools Immune to Prompt Injection?,
studies prompt injection and tool-poisoning risks across real AI development
tools, including Claude Code and Cursor. That is the correct threat model for
coding agents: untrusted context can influence tool use.
A practical Claude Code policy starter
For an individual developer, start permissive enough that the tool is usable:
- allow package managers, test commands, local build commands, and Git status/diff;
- allow reading and writing inside the project workspace;
- allow web fetches to documentation and package registries;
- allow MCP servers you actually use.
Then deny the obvious failure modes:
- block
.env,.aws/,.ssh/,credentials*, private keys, and token files fordata.file.read; - block recursive deletes, disk formatting, privilege escalation, and direct production database CLIs for
system.command.execute; - block writes outside the repo unless explicitly approved;
- block unknown MCP servers and unknown MCP tools in strict mode.
The policy should be easy to explain to a developer: "You can work normally in
the repo. You cannot read secrets, mutate production, or call unapproved tools
without a policy change."
The enterprise version: deploy once, repair always
For one developer, the npx command or curl installer is enough. For a team, the same flow can be wrapped by IT deployment tooling so every developer gets a passport-bound Claude Code setup without manual dashboard work.
The important rule is that the device or developer should keep using the same passport after reinstall. Reinstall should repair the hook and config, not mint a new identity every time.
That gives IT three useful scripts:
- install: create or reuse the device/developer passport and configure the Claude Code hook;
- enforce: detect removal or drift and repair the hook/config without minting a new passport;
- uninstall: clean removal by an admin when the deployment is retired.
How this compares to built-in Claude Code security
Claude Code has meaningful built-in controls. Anthropic documents security best practices, permission settings, and hooks. You should use them.
APort is not a replacement for those controls. It is an additional authorization
layer for teams that need a central answer to:
- Which passport is this Claude Code instance using?
- Which policies apply to it?
- Which tool calls were denied?
- Can we suspend the passport and stop future actions?
- Can an auditor inspect the decision trail?
If you only need local individual control, Claude Code's built-in permissions may
be enough. If you need organization-level guardrails, audit, and a portable
identity that can move across Claude Code, Cursor, OpenClaw, LangChain, and
CrewAI, use an agent passport.
Bottom line
Secure Claude Code by controlling the tool boundary. Prompts can ask the model to
be careful. A PreToolUse guardrail can refuse the action.
If the setup is slower than the risky path, developers will skip it. That is why
the 60-second path matters: create passport, create setup key, install hook, and
start logging decisions before Claude Code touches files, shells, web, or MCP.
Sources and further reading
- Claude Code security documentation
- Claude Code hooks reference
- OWASP Top 10 for LLM Applications
- OWASP Top 10 for Agentic Applications announcement
- Are AI-assisted Development Tools Immune to Prompt Injection?
- Why AI Guardrails Need to Run in the Hook, Not the Prompt
- What Is APort? Pre-Action Authorization for AI Agents
Frequently Asked Questions
Common questions about this topic.