Nobody Reviews What a Vendor's Agent Is Allowed to Do
A vendor security questionnaire asks what software may see and store. It does not ask what software may do. That gap was harmless while software read and…
Open the security questionnaire your company sent to its last three software purchases. Sort the questions into two piles: what the vendor may see or store, and what the vendor's software may do inside your systems. The first pile runs for pages. The second is nearly empty. A vendor agent enters through that same intake, which prices exposure while the product takes actions. Third-party write access is being approved through a process designed for a database with a login screen. The first pile is well drafted. Encryption at rest and in transit. Retention periods. Subprocessor lists. Breach notification windows. The emptiness of the second pile is not negligence. It is the design assumption showing. Vendor risk management matured around one worst case: the vendor holds your data and the data escapes. Software in that model reads and reports, and its failure is a leak. An instrument built to price leaks is silent about everything else, and a vendor agent is everything else. Large companies do own a control for this. Privileged access management exists, and change control governs what may write to a system of record. Both govern internal administrators and the scripts your own engineers wrote, and both are enforced when an employee requests access. A purchased agent arrives on the vendor path, which ends in a security review that never asks the access question and a contract that never names an action. That control is not on the path this purchase travels. A read-only integration that fails produces a wrong report, and somebody finds the number implausible and files a ticket. A write-capable agent removes that person by design, which is the entire value proposition. What differs in kind is attribution. The write arrives as a service account name, and a service account maps to a vendor, not to anyone who can be asked what they were thinking. Assemble the failure from parts every organization already has. A vendor agent clears a standard SaaS security review and is issued a key from the integration profile every vendor before it received, widened years ago for an older sync and never narrowed. It runs a bulk update across opportunity records the vendor's own interface would never permit, because the interface enforces a rule the API does not. A wrong action reproduces across every matching record before anyone opens a dashboard. The audit log names the integration. It names no one. Four questions do the work, and an honest vendor answers all four in an afternoon. Permitted actions. Not the feature list, the action list: every write the agent can perform, each one named, with a mark against the ones it executes without a human confirming. Blast radius. Other systems read a system of record, and a change to an opportunity stage fires a notification, moves a forecast, releases a commission accrual, and sends a customer an email. Reversing the write restores the field. It does not recall the email. Actor identity. What appears in your audit log when the agent writes, and whether it carries a distinct name per class of action. Permission scope below the interface. The credential a vendor issues carries more capability than the product you bought, and the constraint you watched in the demo lives in the interface, not in the grant. Security is chartered over the vendor's controls on your data. Procurement reviews commercial terms, continuity, and price. Legal reviews liability for a breach. None of them covers what a third-party system may do inside a system of record, a question that until recently had no referent. The purchase requires architecture diligence performed on a vendor, and it gets settled in a configuration screen by whoever runs the integration that week. Categories in vendor risk get written after the loss. This one will be written the same way, and the only variable is whose incident does the writing. We scope a purchased agent the way we scope a build, because only the author of the system changes. The code we build lives in the client's repository and runs on the client's auth. A vendor's agent does neither. Ask before the key is issued.