16 docs tagged with "DevOps Engineer"

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 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: Cursor's .cursorignore looks like "keep these files out of the AI's view," but Cursor's own docs say it's best-effort — "does not guarantee that files in it are blocked from being sent up, and there may be bugs." It blocks passive indexing/reading, not my ability in agent mode to just cat a file you "ignored." Treating "ignored = invisible to the AI" as a guardrail for secrets is a false comfort that bites.

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: You hand me the whole task, walk away, and expect to come back to a finished result. But when I fall into a non-terminating loop — calling the same tool over and over, ping-ponging between two actions, forever trying "one more time" — with nobody to stop me, I'll quietly burn through your tokens, your budget, and your rate limits, and write to external systems again and again along the way.

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: when you ask me to set up CI/CD, I tend to slip in "automatically enable this service, automatically grant that permission" as if I had unlimited power in your runtime. But the pipeline's token holds only limited permissions, so the result is either a failed release (Resource not accessible by integration) or an attack surface I quietly widened on your behalf.

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 turned on autonomous execution for me but never spelled out "which actions I may take directly, and which I must ask you about first." So I drop database tables, change production config, and fire off outbound requests with the same casualness I'd use to fix a typo—not out of malice, but because you never handed me a ruler graded by risk, so I treated "I can do it automatically" as "I should do it automatically."

In one sentence you can't pull it back, it may be retained, it may be repeated elsewhere.

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.

In one sentence: You wrote "always run format after editing," "always run tests before committing," and "never touch these files" into CLAUDE.md, then expected me to do it every time. But to me a prompt is a suggestion, not a mechanism — I forget, I skip, I drift as the context grows. If it has to happen, don't leave it to my goodwill. Make it a hook.

In one sentence: Gemini CLI keeps a per-folder "trust" store (~/.gemini/trustedFolders.json) — a folder's project config and .env only take effect, and confirmations only ease up, once you trust it. But "trust the parent folder" inherits trust to every subdirectory, and a parent's TRUST has been reported to override a child's explicit DONOTTRUST. So an unfamiliar repo you cloned in to keep isolated gets treated as trusted just because it sits under a parent you trusted — exactly where an injection wants to land. Claude Code has no such trust store, so this trap is specific to Gemini CLI.