# AI Coding Assistant Refusals on IP Copying: Constraint Logic and Engineering Countermeasures

1. What Happened: Two Lines of Prompt Text Reset the Tool’s Output Boundary

The dispute started small. Developers noticed that a terminal coding assistant had shipped a new set of “Do & Don’t” rules in its underlying configuration:

• Allowed: helping build original games, publicly known genre mechanics, and games based on the user’s own design and own assets.
• Not allowed: rebuilding one specific existing title — including reimplementations under a new name, or implementations repackaged as “original.”

Once the configuration became public, another group of developers reported being refused in everyday work. Some only wanted the tool to read a segment of harmless decompiled output and summarize its modules. Some wanted a routine comparison of competitor physics collision parameters or a benchmark of feel-tuning curves. Some were simply maintaining an ancient codebase whose source and comments were long gone. All of them got the same flat refusal.

The vendor’s engineers later confirmed on social media that the two constraints had indeed been added to the system prompt of a newer model version (Opus 5.5), with the goal of reducing intellectual property infringement risk.

This is worth stating precisely: it is not a model capability regression. It is a product strategy being made explicit. The strategy was written into the inference-time system prompt layer, which gives it two characteristics at once — fast to ship, and broad in its side effects.

2. Why the Constraint Was Put in the System Prompt Layer

There are generally three places to intervene when imposing copyright constraints on a generative model:

1. Training data layer: cleaning protected content, signing data licensing agreements, deduplication and copyright filtering. Most thorough in effect, but expensive, planned in quarters, and for existing models it means retraining or fine-tuning.
2. Product terms and account layer: relying on user agreements to govern use, then rate-limiting or banning violators. This is after-the-fact accountability; it cannot stop a single generation.
3. Inference-time system prompt layer: injecting policy text before each request. It can ship in hours, support canary releases, A/B tests, and one-click rollback, and it can be customized for a single content category.

Choosing the third layer is a completely reasonable engineering decision — while the rights chain is still unresolved, it is the only lever that lowers risk immediately. But it has four inherent flaws that must be written down in the design document:

• Non-determinism: sampling the same request several times can yield inconsistent verdicts, so users experience “sometimes refused, sometimes allowed.”
• No rights facts: the prompt only sees a natural-language description. It cannot know whether the caller holds authorization, or whether the target work is the caller’s own asset.
• Fragile intent inference: rephrasing, chunking, step-by-step questioning, and describing things in another language all get around it; conversely, neutral technical descriptions get misclassified.
• No awareness of context assets: the tool does not know the state of the user’s asset library, build artifacts, or license ledger.

Conclusion: pushing rights determination entirely onto the system prompt layer will inevitably produce both a high false-refusal rate and a high bypass rate. It is a transitional measure, not an end state.

3. Why the Collateral Damage Clusters in Three Scenarios

1. Mods and derivative development. The goal is “make a copy I legally own run better,” and the actual work lands in engine behavior, save-file formats, script hooks, and asset packaging structures. But when asking the question, the user will almost certainly name the target title — so the behavior is legitimate while the description trips the ban.

2. Legacy code maintenance. Facing decompiled output, the model’s position is “here is code that is not part of my training corpus.” It cannot distinguish two situations: a user analyzing their own company’s legacy assets, versus a user reproducing someone else’s work. A conservative policy refuses everything, and the false-refusal rate goes through the roof.

3. Competitive analysis and parameter benchmarking. Physics collision detection, performance baselines, and comparisons of feel-parameter ranges are all standard engineering work. But since the comparison output can be used directly to “reproduce the same feel,” the tool chooses to err on the strict side.

The root cause is the same in all three: the system prompt layer has no input channel for “rights facts,” and it does not separate the act of “analyzing” from the act of “generating.”

4. How to Write the Constraint: From Noun Bans to Behavior Bans

A ban centered on titles (refuse whenever a certain name appears) hits legitimate analysis and legitimate inspiration alike; a permission centered on genre (anything in the same genre is fine) is too loose. A more maintainable approach judges three elements:

Dimension	Question to answer
Target artifact	Is the output an analysis document / diagnostic recommendation, or a directly runnable implementation?
Structural similarity	Do level data, numeric tables, state machines, or asset layouts map one-to-one onto the protected copy?
Asset provenance	Do the code, art, and audio come from the protected copy or from an untrusted source?

Rewriting the user’s request along these lines drops the false-refusal rate noticeably:

• ❌ “Build a game in the same genre as [title].”
  ✅ “Implement the core loop of that genre without using its level data, numeric tables, or original assets; parameters come from our own design document.”
• ❌ “Analyze this decompiled code.”
  ✅ “This is a legacy build artifact of our own product (ticket IP-2231). Output only module responsibilities, control-flow summaries, and defect-localization suggestions; do not reconstruct compilable source.”
• ❌ “Compare the collision behavior of these two games.”
  ✅ “Compare the parameter ranges in our implementation against a published benchmark, flag the deviations, and do not restate the other side’s concrete implementation structure.”

The essence of this phrasing is: replace “what I am doing” with “what artifact I want plus where the assets come from” — turning an undecidable question about intent into a decidable question about artifacts and provenance.

5. Six Things Engineering Teams Can Ship Right Now

5.1 Build an Asset Provenance Manifest

Make “rights facts” machine-readable data instead of something explained in conversation.

asset_provenance:
  - path: src/gameplay/collision_solver.*
    origin: first_party          # first_party | licensed | public_domain | clean_room
    license: proprietary
    ticket: IP-2231
  - path: assets/level/level_0007.json
    origin: clean_room
    derived_from: "internal design doc DD-118"   # internal doc ID only
    reviewer: ip-review-board
  - path: third_party/audio/*
    origin: licensed
    contract: CTR-2024-091
    expiry: 2027-03-31           # alert 90 days before expiry

Put the manifest in version control and use it as the single source of truth for all automated checks.

5.2 Standardize Team-Level Prompt Templates

Fix the three elements from Section 4 into a template so nobody has to do “trial-and-error asking” on their own.

[Role] You are maintaining a legacy build artifact of our own codebase.
[Rights] Rights to this artifact belong to us; the ticket ID is in the input.
[Constraints] Output only module responsibilities, dependencies, control-flow
             summaries, and defect-localization suggestions. Do not output a
             directly compilable full implementation and do not reconstruct
             the missing source files.
[Output format] Markdown with four sections: Modules / Dependencies / Risks / Suggested changes

5.3 Move Similarity Checks into the Pipeline

Do not rely on the model’s self-restraint; use deterministic algorithms as gates. On the code side, use token-level n-gram fingerprints plus locality-sensitive hashing (LSH) for approximate retrieval. On the data side, compare level and numeric tables field by field and structurally. On the asset side, compare file hashes and perceptual hashes.

def ip_gate(change_set, provenance_db, protected_index, license_policy):
    findings = []
    for f in change_set.files:
        if not provenance_db.is_allowed(f.path, change_set.project_id):
            findings.append(Finding(f, "UNTRACKED_ORIGIN"))
        for m in fingerprint(f).nearest(protected_index, threshold=0.85):
            findings.append(Finding(f, "STRUCTURE_SIMILARITY", detail=m))
    for dep in change_set.dependencies:
        if license_policy.family(dep) == "STRONG_COPYLEFT" \
           and change_set.distribution == "BINARY":
            findings.append(Finding(dep, "LICENSE_INCOMPATIBLE"))
    return findings      # non-empty blocks the merge and routes to human review

The threshold (0.85 here) must be calibrated by regression against your own historical data; never adopt any default value as-is.

5.4 Third-Party Components and a License Ledger

Generate a software bill of materials (SBOM), classify it into three tiers — permissive / copyleft-infectious / forbidden — and verify that the distribution model is compatible. Asset expiry and license version changes should both trigger pipeline alerts.

5.5 Human/AI Division of Labor and Audit Trails

Set the policy explicitly: analysis-type requests default to permissive, generation-type requests default to strict. Tag and log every file that AI participated in generating, and retain the request records, the provenance manifest version, and the reviewer’s signature to form an auditable chain. When a dispute arises, what you need is an evidence chain, not an explanation.

5.5 Keep the Hosting Layer Generic

All of the above can be built from industry-standard cloud building blocks: object storage for archiving assets and build artifacts with version management, a container platform for running batch fingerprinting and license-scanning jobs, and a logging service with monitoring and alerting to close the loop on gate results and expiry reminders. Baidu AI Cloud offers corresponding products in these general categories; teams can pick according to their existing stack, with no need to bind to a specific implementation.

6. Four Design Recommendations for Platforms and Tool Vendors

• Explainable refusals: say which policy was hit, which type of risk it is, and what material can be submitted to request an exception — instead of a flat “I can’t help with that.”
• Tiered authorization: let enterprise tenants submit asset manifests or license evidence in exchange for broader permissions on analysis-type requests; turn “rights facts” into an explicit input channel.
• Push constraints down: move from the prompt layer down to the retrieval layer (assets may only be pulled from an authorized library) and the tool layer (restrict which files can be read, block export of specific structures). That is far more reliable than guessing intent in natural language.
• Metric-based governance: treat false-refusal rate, bypass rate, and human-review pass rate as release gate metrics, and publish them to users.

7. Conclusion

What actually matters in this dispute is not that “an AI refused a request,” but that the constraint was introduced too late. If the rights chain had been resolved back at the training-data and asset-licensing stage, the risk would never have needed a single line of prompt text at inference time as a backstop; once the only option is hard blocking on the output side, the cost is inevitably borne by large amounts of legitimate productivity — mod authors, legacy-system maintainers, and engineers doing parameter calibration all end up sharing the cost of misjudgment.

The workable direction is to engineer rights facts: an asset provenance manifest, a license ledger, similarity baselines, and audit trails. When that data is in place, the model no longer needs to guess intent to judge risk — it can allow or refuse directly on the facts.

Team action checklist: ① build the asset provenance manifest and put it under version control; ② standardize team-level prompt templates; ③ wire similarity gates for code, data, and assets into the pipeline; ④ land an SBOM with license tiering; ⑤ define different default policies for analysis-type and generation-type requests; ⑥ set false-refusal and review-pass metrics and review them per release.