Preventing Windsurf Cascade Agent Edits from Pulling in Copyleft Dependencies

Where copyleft enters a Cascade session

A Cascade session can change many files in one multi-step run, so licence risk is not limited to a single obvious `install` command. Four entry points matter for policy design.

The first is direct manifest and lockfile edits. The agent adds or upgrades a package in a manifest, and the lockfile records the resolved versions. The second is transitive dependencies. A package with a permissive licence can pull in a dependency under a different licence, and the agent never names it. The third is terminal command execution. Package manager commands, build scripts and download commands can add code that never appears in a manifest. The fourth is generated or pasted source. A snippet written into a source file has no package metadata, so a manifest scanner cannot see it, and the model's own training data origin is often not disclosed by its developer, so the origin of generated code cannot be assumed.

Each entry point needs a different control. Manifest edits can be checked against a licence list. Transitive dependencies need the resolved tree. Commands need a decision before execution. Snippets need provenance information attached to the interaction that produced them.

Define a licence policy a machine can enforce

Start with the obligations your organisation actually has. Whether software is distributed to customers, offered as a hosted service or used only internally changes which licences are a problem, so the policy should be written per product or repository class rather than once for the whole company. Have legal counsel confirm how GPL, LGPL, AGPL, MPL and SSPL apply to each class before the policy is encoded.

Then reduce the result to three outcomes. Allow covers licences your counsel has cleared for that repository class. Deny covers licences that conflict with your distribution or licensing model, which for many teams means strong or network-triggered copyleft. Escalate covers everything in between: weaker copyleft licences, dual-licensed packages, unknown or missing licence metadata and any licence expression the policy cannot parse. Treating unknown as escalate rather than allow is the decision that matters most, because agents routinely add packages with incomplete metadata.

Version the policy and give each version an identifier. Every later decision, and any exception granted, should reference that identifier.

What each control can and cannot do

No single control covers all four entry points. The table summarises where each layer is strong and where it stops, so the gaps are explicit before you design around them.

• Windsurf rules and instructions: Guide the model toward approved packages and licences. They shape behaviour but are instructions to a model, so they are not a verifiable enforcement boundary.
• Command and tool permissions: Restrict which commands and MCP tools Cascade may run or must confirm. They act on the command or tool, not on the licence of what the command installs.
• Pre-commit hooks and PR checks: Evaluate the change after the agent has written it. They are effective gates for merging but do not show what the agent was permitted to add.
• SCA, licence scanners and SBOMs: Inventory components and licences, which is useful supply chain evidence. Scans are periodic or pipeline-timed, so detection follows the edit.
• Runtime enforcement in the execution path: Evaluates an individual interaction or tool call before it takes effect and records the decision. Its scope is that interaction, not the whole workflow.

Implement the layers in order

Build from the cheapest control to the most specific, and treat each layer as covering the failures of the one before it. NIST material on software supply chain security places controls inside CI/CD pipelines and treats open-source components as a pervasive supply chain concern, which supports keeping CI as a layer. A January 2026 federal request for information on AI agent security lists tool restrictions and continuous monitoring among agent system-level controls. That request concerns security, not licences, but the same layered shape applies.

• 1. Encode the policy: Write the allow, escalate and deny tiers per repository class in a versioned, machine-readable file.
• 2. Configure Windsurf: Add rules that name approved licences and registries, and set command and MCP tool permissions so package installs and downloads require confirmation or are denied.
• 3. Gate the repository: Run licence scanning on manifests and lockfiles in pre-commit and CI, including the resolved transitive tree, and fail on denied or unknown licences.
• 4. Enforce at runtime: Place policy enforcement in the execution path so a manifest edit, command or generated snippet is allowed, redacted, blocked or escalated before it is written.
• 5. Route escalations: Send escalated changes to a named approver and record the approval against the policy version.
• 6. Test the controls: Add a known denied package and a known unknown-licence package to a test repository and confirm each layer responds as designed.

Where runtime enforcement closes the gap

Configuration and CI leave a timing gap. By the time a pull request check fails, the agent has already modified the manifest and lockfile and possibly built on the new package. Enforcement in the execution path changes the order: the decision is made on the interaction or tool call, and the change is written only if policy permits it.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants, with actions to allow, redact, block or escalate for human approval. Its code provenance records the origin, licence and security context of code, which gives the policy something to evaluate for generated or pasted snippets as well as for declared packages. Scope matters: enforcement applies to individual interactions and tool calls. It does not provide end-to-end tracing of an agentic workflow, so keep CI and repository checks in place for the full tree.

When you evaluate any enforcement layer, ask four questions. Does it act before the change is written? Does it see resolved and transitive dependencies or only declared packages? Does it cover snippets as well as packages? Does each decision carry the policy version, licence and origin metadata, and the approver for escalations?