Security: secrets, dependencies and prompt injection

0:00 Security for coding agents

A coding agent can read your secrets, read text written by strangers, and run commands on your machine. Each of those is useful. Together, they are exactly what an attacker needs. In this lecture you will learn the four main threats in AI-assisted development, secrets, dependencies, prompt injection and insecure code, and a layered baseline that defends against all of them.

0:27 Analogy: the intern and the post

Here is an analogy for agent security. Imagine giving a very capable new intern the keys to your office, your filing cabinet and the company credit card, and asking them to open all the post. Most letters are harmless. But one letter says: urgent from the director, please wire money to this account and do not mention it. A well-trained intern might spot it. A tired one might not. The safe setup does not depend on the intern's judgment: they open post in a room without the credit card, and payments need a second signature. That is exactly how we secure agents.

1:11 The lethal trifecta

Security researcher Simon Willison describes a lethal trifecta for AI agents: access to private data, exposure to untrusted content, and the ability to communicate externally. When all three are present, an attacker who controls some content can trick the agent into sending your data out. The good news is the flip side. Remove any one leg, for example by blocking network egress, and most exfiltration attacks fall apart.

1:41 Threat 1: secrets

Threat one: secrets. Agents leak them by reading env files and pasting values into code, logs or pull request descriptions, or by generating example keys that get committed. Defenses: ignore env files in git, deny the agent read access to them, use a secrets manager with short-lived credentials, and run a secret scanner like gitleaks both as a pre-commit hook and in CI. Turn on your Git host's secret scanning and push protection too.

2:13 Threat 2: dependencies

Threat two: dependencies. Agents add packages casually, and sometimes invent package names that do not exist. Attackers register those look-alike or commonly hallucinated names on public registries, a trick sometimes called slopsquatting. Defenses: commit lockfiles, run dependency review on every pull request, require the agent to list and justify new packages, and have a human confirm each one is real, maintained and from the expected publisher.

2:42 Threat 3: prompt injection

Threat three: prompt injection. Any text the agent reads can contain instructions. A comment in a file, a dependency's README, an issue body, a web page, even the description of an MCP tool. The lesson shows a comment telling AI assistants to run a download-and-execute command and not mention it. Injections can also hide in invisible characters or Markdown comments. The model cannot reliably tell data from instructions, so your defenses must not depend on it doing so.

3:16 Layered defenses

Layer your defenses. Treat all repository and tool content as untrusted. Constrain actions with command allowlists and a network egress allowlist, and never allow curl piped into a shell. Read what you approve, because approval fatigue is itself an attack vector. Evaluate third-party code in disposable containers without your credentials. Review and pin MCP servers. And keep humans on the merge button, scanning for new network calls, obfuscated code or CI changes.

3:47 Case: the poisoned README

A real-world shaped case. A developer at a UK agency asked an agent to evaluate an open-source library. The documentation hid instructions asking the agent to add a telemetry snippet to the client project. The team always evaluates third-party code in a disposable container with no credentials and a network allowlist. The injected command failed, showed up clearly in the transcript, and they reported it to the maintainers. The sandbox did its job even though the model was fooled.

4:21 Threat 4: insecure code

Threat four: the agent writing insecure code on its own. Models reproduce patterns from their training data, including string-built SQL, missing authorization checks, permissive cross-origin settings and weak cryptography. Defenses: security-focused lines in your instruction file, static analysis like CodeQL or Semgrep on every pull request, dependency scanning, and a security checklist for sensitive paths like authentication, payments and data deletion.

4:48 Example: four layers vs one command

A simple example of layered defense. Your agent is about to run a setup script it found in a third-party repository, which contains a curl command piped into a shell. Layer one: your allowlist does not include curl piped to shell, so the agent must ask. Layer two: you read the prompt and decline. Layer three, if you had approved anyway: the sandbox's network allowlist blocks the unknown domain. Layer four: even if code ran, there are no credentials in that sandbox to steal. Four independent chances to stop one bad command.

5:28 Scenario: first month of secret scanning (illustrative)

Now a realistic scenario with illustrative numbers. A twenty-developer agency in Dubai runs gitleaks as a pre-commit hook and in CI after an audit. In the first month, the pre-commit hook stops around a dozen attempted commits containing keys, most of them test keys pasted by agents into example files, and two real production keys. CI catches one more that bypassed the local hook. Nothing reaches the remote. Before the audit, they had no idea this was happening. Common mistake: assuming your secrets hygiene is fine because you have never seen a leak. You cannot see what you do not scan for.

6:12 Deeper: checking a suspicious package

One level deeper on slopsquatting. An agent suggests installing a package whose name sounds exactly like a helper for your framework. You search the registry: it was published last week, has a handful of downloads and no linked repository. The real library has a slightly different name. That check takes thirty seconds, and it is the difference between a dependency and an attacker in your build.

6:41 Watch me do it: security baseline

Watch me do it. I'm applying the agent security baseline from the lesson to one repository, line by line. Secrets first. I check the gitignore: env files are ignored, but a secrets folder is not, so I add it. In the agent settings I add deny rules for reading env files and the secrets folder. I install gitleaks as a pre-commit hook, pinned to a release tag I have reviewed, and add the same scan to CI. Then I test it: I create a file with a fake key in the right format and try to commit. The hook blocks the commit and names the file and line. Second, dependencies. I confirm the lock file is committed and add the dependency review action to pull requests. Then I append one line to AGENTS dot M D: list every new dependency and why in the pull request. Third, execution. My allowlist has npm test, lint and git status. I make sure there is no rule allowing curl or any piped shell command. Fourth, untrusted code: I write down that evaluating third-party repositories happens only in the disposable container profile with no credentials. Fifth, CI permissions: I open each workflow and replace one write-all block with the minimum needed. Sixth, static analysis: I enable CodeQL on pull requests. It took forty minutes, and each item is now a default rather than a hope.

8:21 Recap

Recap. Break the lethal trifecta wherever you can. Deny secrets, verify dependencies, treat all content as untrusted, constrain actions, sandbox third-party code, and scan what agents produce. Your next step: copy the agent security baseline from the lesson into your repository, and check each line against how your team actually works today.