Here are some pointers for managing Model Context Protocol, dependencies, and agent permissions in the AI coding era

Several risks deserve particular attention:

• Attacks via MCP servers
  Model Context Protocol (MCP) servers give AI agents access to external data and tools. They can introduce risks including context poisoning, command injection, and token theft.
  MCP-related packages can also be malicious.
  Before adding an MCP server, review its source code, publisher, release history, requested permissions, and network activity. Restrict the data, credentials and systems it can access.
• Indirect prompt injection
  This occurs when malicious instructions are placed in content an AI system retrieves from an external source, such as a documentation page, issue tracker, dependency README, or code comment. An agent may treat that content as an instruction rather than data. This is particularly relevant to agentic workflows that can browse the web, read repositories, use tools, or execute commands.
  Treat all externally retrieved content as untrusted. Limit what agents can do with that content, require approval for consequential actions, and separate read-only research tasks from tasks that can modify code, infrastructure, or data.
• Hallucinated dependencies
  AI models can generate plausible but nonexistent package names. Attackers may register those names and publish malicious packages, a technique known as slopsquatting. The same issue can apply to URLs: a model may generate a non-existent domain, which an attacker can register and use for phishing or malware distribution.
  Check dependencies before installation. Verify a suggested package before installing it. Check whether it exists in the official registry, when it was published, how many downloads it has, whether its repository URL points to a real source repository, and whether the maintainer has published other packages.
  Be especially cautious with packages that are newly published, have few downloads, lack a source repository, or have a name similar to a well-known library.

Check the dependencies

In view of the risks, consider using Software composition analysis (SCA) tools to scan dependency trees against databases of known vulnerabilities:

• ✓ Run SCA continuously in CI rather than relying on manual checks. Define a policy for handling findings, such as failing builds on critical-severity vulnerabilities or requiring review before merging.
  SCA can identify known vulnerabilities and outdated dependencies, but it may not detect a newly published malicious package before that package is added to vulnerability databases.
• ✓ Also, generate a software bill of materials (SBOM) including direct and transitive dependencies, versions, licenses, and hashes, as a build artifact in a standard format such as CycloneDX or SPDX. When a vulnerability is disclosed in a widely used library, an SBOM can help teams determine whether their products include the affected component.
• ✓ Pin versions and verify integrity: commit lockfiles to version control, and use integrity hashes where the package ecosystem supports them. Verify package signatures where available.

These controls can help detect unexpected changes to dependencies and reduce the chance that a modified or malicious package is silently installed.

Limit agent permissions

Additionally, AI agents should have the minimum permissions needed for their task. Avoid giving coding or operations agents broad production credentials, unrestricted network access, or the ability to delete resources without approval.

Use role-based access controls, short-lived credentials, environment separation, and approval workflows for destructive actions. Ensure backups are isolated from the systems and credentials that could delete production data.

In an April 2026 PocketOS incident, a coding agent reportedly encountered a credential error in a staging environment, found an over-privileged token in unrelated files, and used it to delete a production database and its attached backups in nine seconds. The incident was attributed to excessive permissions, a shared blast radius between production data and backups, and the agent’s ability to act without a human approval step.

Several factors almost always converge in incidents like these: on one side, an agent acting on guesswork; on the other, excessive permissions, inadequate privilege separation, and a poorly configured execution environment. The agent is the trigger, but the root cause is a gap in the engineering safeguards.

Scale review with AI-generated code

AI can increase the volume of code that needs review. Pair automated checks — tests, static analysis, dependency scanning, and policy checks — with human review for security-sensitive changes:

• ✓ Require review for changes involving authentication, authorization, secrets, infrastructure, dependencies, data deletion, and external integrations.
• ✓ Ensure reviewers have enough context to assess not only whether code works, but also what external content, tools, and credentials it can access.

The engineering gap that needs addressing

The issue was never whether AI could be trusted. Careful code review has always been necessary. What has changed is the balance: we have dramatically expanded our capacity to generate code, while review quality has remained unchanged and is no longer adequate for the way we now work.

Review effectiveness now needs to scale with code-generation capacity if we are to keep code quality under control: automate checks wherever possible and use expert human review wherever necessary.