16 docs tagged with "security"

In one sentence low-risk runs automatically, high-risk forces a human review, irreversible gets a dry-run first. Wire it straight into your settings and hooks.

In one sentence: a permissions block you can paste straight into settings.json — deny nails down the operations I must never touch, ask gates writes / pushes / installs behind a confirmation, and allow whitelists high-frequency read-only ops. Drop it into your project's .claude/settings.json and trim a few lines to fit your stack.

In one sentence: turn your data-boundary policy into a tier table you can use as-is. AI can't tell on its own whether a given piece of data is allowed to leave the company boundary — data sensitivity is your policy, and if you don't spell it out, AI treats everything the same and uses it. Classify the data first, then decide what must never enter an external AI, what's fine once it's de-identified, and what's fine because it's public.

In one sentence a malicious instruction buried in an issue I read, or a web page I fetch, can ship your data outward through the tools already in my hands.

In one sentence: during setup you hand me --dangerously-skip-permissions and auto-approve every tool call, because you don't want to be interrupted. What you also hand over is the one chance to stop things at the moment they go wrong — and the thing that goes wrong might not be me, but an injected instruction hidden in a file, acting through my hands.

In one sentence: the PR description says "just a small refactor, no logic change," and when I review it I nod along with that framing; you see "AI Review Passed" and rubber-stamp the merge. Two gates that were supposed to be independent—one deferring to the author, one deferring to the AI—and in the end neither of us actually looked at that code. The review gate collapses into a conveyor belt.

In one sentence exfiltrate a secret, plant a backdoor in the diff, run a destructive command. This isn't your shipped product getting attacked — it's me, mid-coding, getting hijacked by poisoned content right now.

In one sentence hardcoded keys committed to the repo, endpoints left unauthenticated, and sensitive data written into logs and error messages.

In one sentence: logs are the only foundation you have for later determining "what the AI actually did," but they are themselves an attack surface. I'll write unescaped external input straight into the log (letting an attacker forge log lines and fool the SIEM), and I may also fail to record key actions; conversely, when I read a poisoned log, it can mislead me. Once the logs are dirty, the audit trail breaks—and when something goes wrong, you can't reconstruct the truth.

In one sentence: run AI-generated code (mine included) through this checklist before you ship — security is a non-functional requirement I default to not seeing, and when the feature works, vulnerable code looks identical to safe code. Paste it into your PR template or release ticket and tick every box before release.

In one sentence paste something sensitive to me, and it leaves the perimeter you control.

In one sentence leaking data, calling tools it shouldn't, bypassing the rules you set. During development I default to assuming "all input is benign," so I treat a release surface that should be modeled as an attack surface like an ordinary feature delivery.

In one sentence: you have me add features, fix bugs, and refactor round after round, and the code does look better and better — but security vulnerabilities quietly accumulate with the number of iterations. Research finds severe vulnerabilities rise significantly after just five rounds. A process that "looks like it keeps improving" is actually getting worse on the security front, and by release time it's hard to walk back.

In one sentence the source code, secrets, and data I read, I can encode into a URL and send to an attacker's server—which is exactly the third leg of the "lethal trifecta" that most deserves to be cut.

In one sentence: you control what commands I can run with "soft permissions" like allow / ask / deny, but the process I run commands in shares the same domain as your entire machine, your credentials, and your network. Soft permissions are a policy that I (or the malicious content I read) can try to circumvent — not a wall the operating system enforces. The moment a prompt injection hijacks me, I can reach your SSH key, your environment variables, your whole filesystem, and the outbound network.

In one sentence\ProgramData), and nobody checks who owns that directory or who dropped the file. So a low-privileged local user just drops a config there, attaches a "run on every startup" hook, and I execute their command as every user who launches me—including administrators—with no elevation, no confirmation from you, and no warning.