Snyk says model risk is set by what an agent can reach

Security teams scoring AI models in isolation are only seeing part of the problem, according to a blog post published by the developer security vendor Snyk on 21 October 2026. The company argues that the risk a model carries in practice depends on what the application built around it can reach: the data it can read, the tools it can call, and the actions it can take.

The argument matters most for agentic systems, where a model is not simply answering questions but is wired into other software. In that setting the same model can be close to harmless in one deployment and dangerous in another. A model with a mediocre safety score that can only draft text has a narrow blast radius. The same model given a database connection, a mail client and permission to execute code has a much wider one. Snyk's position is that the second case is the one a risk register should capture, and that a score attached to the model alone will not capture it.

Snyk frames this as a question security teams can answer empirically rather than on trust. The company says teams should verify a model's reach, meaning establish what the application actually connects to in production rather than what its design documents claim. In agent deployments, reach tends to accumulate quietly: a tool is added for one workflow, a credential is broadened to unblock a test, an integration is left enabled after a pilot. Verification is the step that turns an assumed boundary into a measured one.

The second half of the company's advice is to pick controls that match that reach. Snyk describes these as targeted controls, the implication being that blanket restrictions applied to every model are both expensive and poorly aimed. If an application's main exposure is a tool that can write to a production system, the control belongs at that tool. If the exposure is a data source containing customer records, the control belongs at the data layer. Choosing where to spend effort requires the reach map first.

None of this is a disclosure of a flaw or an incident. It is guidance, published by a vendor that sells security tooling for developers, and readers should weigh it accordingly. The underlying point is nonetheless a familiar one in agent security: the model is the component that gets the attention and the benchmark scores, while the permissions wrapped around it are what determine the consequences when something goes wrong. This article is based on the published summary of Snyk's post.