Vulnerability Management for Agent Platforms

An agent stack has three patch regimes, not one.

Standard vulnerability management assumes a uniform world: a CVE is published, you locate the affected version, you deploy a fixed one, you verify. Agent deployments break that uniformity because the three tiers of the stack fix things on completely different clocks.

• Code you wrote — tool implementations, prompts, orchestration, the glue that decides what the agent is allowed to attempt. Your release train. Patch latency measured in hours, verification is a commit and a test.
• Components you self-host — the gateway, MCP servers, the browser runtime, sandbox base images, the serving stack. Someone else finds the bug, you pull the image and redeploy. Patch latency measured in days, verification is a digest in your registry.
• Agent services the vendor operates — the SaaS agent holding a credential in your environment. The fix is already live when the advisory reaches you. Patch latency is zero and verification is impossible: no build number, no artifact, no rollback.

Most programmes are built entirely for the middle tier, which is the tier holding the least authority. The third tier is where the credentials are, and it is the one your tooling cannot see. Start by writing down which of your agent capabilities lives where — the same census as agent inventory & registry, sorted by who ships the fix.

Inventory the credential, because the credential is the severity.

For an agent product, the CVSS score of a future authorization bug is largely determined before the bug exists. A scope-changed vulnerability — where the impact crosses out of the vulnerable component into everything it was trusted by — scores on the size of the reachable set, and that set is your role assignments, not the vendor's code.

• Record the identity, not the product. "We use an SRE agent" is not an inventory entry. "Service principal sre-agent-prod holds Contributor on three subscriptions and can write runbooks" is.
• Score each identity by what it could do if one authorization check failed tomorrow. That is a five-minute exercise per identity and it produces a ranked list of grants nobody can justify. Removing the top item is the highest-leverage security action available on this stack.
• Split identities by capability and environment. One credential that can both read telemetry and mutate infrastructure turns an information-disclosure bug into a persistence bug. Two credentials do not — the argument in scoped credentials for agents.
• Treat pilot-era grants as expired by default. Agent products are provisioned generously during evaluation and re-scoped approximately never, because narrowing a permission is work nobody is rewarded for. Put an expiry on the grant so the default is revocation.

A service-side fix deletes most of your programme. Know what replaces it.

Walk the standard remediation steps against "no customer action required" and most of them evaporate. This is not a reason to skip the ticket; it is a reason to write a different ticket, with different questions.

• Asset inventory learns nothing — there is no build number. Replace with: record the advisory against the identity, not against a version.
• The scanner cannot confirm remediation — there is no patched version to detect. Replace with: the vendor's statement, filed as the compliance artifact, and an explicit note that you could not independently verify it.
• Change control has nothing to approve — the change already happened, without your window. Replace with: a retroactive review of what the agent did during the window.
• There is no rollback — the only reversal available to you is revoking the agent's access, which is a business decision, not an ops one. Decide in advance who makes it and how fast, per kill switches.

What survives is three questions, all about your environment: what could the identity reach during the window, what did it actually do, and would you have noticed. Notice that none of the three can be answered by acting after the advisory arrives.

The window you have to reconstruct starts before the disclosure date.

A disclosure tells you when the fix shipped. The interval a security team actually has to reason about runs from when the defect was introduced, which for a service-side fix you are usually never told. Assume it is the whole life of the feature until the vendor says otherwise.

• Retention is the capability, not the cost line. If control-plane logs retain ninety days and the feature shipped eight months ago, "were we affected" is permanently unanswerable. That is a decision you made in a storage budget meeting and will discover in an incident — the same argument as trace sampling & retention, applied to security evidence.
• Log the agent's actions independently of the vendor. Cloud-provider activity logs, your own gateway logs, and your application's audit trail are yours; the vendor's console is theirs and may not be exportable at all. Ask before you sign, not during an advisory.
• Keep the human principal on the record. When the agent acts for a user, both should be named in the audit entry. A broken on-behalf-of exchange is precisely what destroys that link, which is why you want it recorded somewhere the agent does not control — decision receipts & audit.
• Baseline the non-human identity. An agent's credential has an extremely regular signature: a stable set of resource types, from a stable set of callers, on a schedule that tracks its triggers. Deviation alerting on a service principal is far more tractable than on a human, and almost nobody does it.

Do not let the self-hosted tier rot behind the exciting one.

The tier you can patch is the tier that gets forgotten, because it looks like ordinary infrastructure and does not generate advisories with the agent's name on them. It is also where an agent's dependency graph is unusually wide and unusually fresh.

• MCP servers are dependencies with tool-call authority. Many are young, single-maintainer packages that your agent invokes with production credentials. Pin them, review what they can reach, and track them as first-class supply chain — agent supply chain security.
• Sandbox and browser images age badly. A code-execution sandbox or a headless browser is a full operating environment; the base image accumulates CVEs at the normal rate and gets rebuilt at the rate of your attention. Put it on a scheduled rebuild, not an event-driven one.
• The gateway sees every prompt and every response. It is a high-value target with cleartext access to whatever your agent handles. It deserves the patch cadence of an authentication service, not of a proxy.
• Model and runtime upgrades are not security-neutral. A model change can move refusal behaviour and tool-use reliability at once; treat it as a change requiring the same evals, per model deprecation & migration.

Write the vendor terms while you still have leverage.

Everything above is downstream of a procurement conversation that happens once, before signing, when the vendor still wants the deal. Two questions do most of the work and neither is on a standard security questionnaire.

• What is your notification commitment for a fix applied without customer action? "We patch service-side" is a benefit only if you are told. Ask for a defined window and a named channel, and check whether it covers vulnerabilities discovered internally rather than only those with a CVE.
• Can I export control-plane logs of the agent's actions in my tenant? If the answer is a console you can look at but not query, you cannot run step 4, and you should price that in now.
• What identity does the agent use downstream, and can it be scoped per capability? A product that only supports one broad managed identity has set your severity ceiling for you.
• What is the exit? Revoking access mid-incident should not take down a workflow nobody has a manual path for — exiting a managed agent runtime and third-party model & vendor risk cover the rest.

Related: the agentic threat model for where this sits among the other attack paths, incident response for agents for running the response itself, and serious incident reporting for when the disclosure obligation runs the other way.