Refusing to Hand Over Control: LLM Supply Chain Governance and Boundaries

1. The Real Source of the Conflict: Not Technology, but Who Defines the Boundaries of Use

Supply chain risk assessments, such as security reviews or risk registries, often coexist with actual business use. This combination is not a contradiction. Instead, it reveals a more fundamental disagreement: the buyer and the supplier have a structural conflict over who holds the authority to define the boundaries of model use.

Suppliers generally hold two non-negotiable red lines: autonomous weapons capability and large-scale surveillance of citizens. These are not radical positions. Nearly every mainstream AI risk governance framework lists them at the top of its warnings.

Buyers work from a different logic: once technology has been procured, the standards and procedures for its use should be determined by the buyer itself. They do not want to accept supplier-imposed usage terms in the contract, and even less do they want a supplier embedded in the command chain or the decision-making process.

Each position is internally consistent, but they cannot be reconciled. One side insists on “the contract as the boundary”; the other insists on “the process as the boundary.” A breakdown in negotiations is almost a structural outcome, with little to do with any particular vendor’s negotiating skill.

The lesson for enterprises is direct: any approach to defining usage boundaries “through the contract” ultimately has to be backed by technical controls. A contract can only stipulate outcomes. Permissions, auditing, residency, and circuit breakers can only be truly enforced at runtime.

2. Breaking “Control” Down into Implementable Engineering Objects

Abstract “control” cannot be governed. It has to be broken down into four implementable gates.

1. Identity gate

Who is allowed to call the model? Authorization for AI applications must be fine-grained across four layers: user, service identity, session, and data source. A common failure pattern: authentication is done well at the gateway, but the agent’s downstream tool calls reuse the same service credentials, so least privilege breaks down at the second layer.

2. Data gate

What data can the model read? The input side needs to distinguish three categories:

• Public data that can enter the context directly
• Sensitive data that requires redaction or field-level filtering
• Highly sensitive data that is prohibited from leaving the environment

At the heart of the data gate is a simple rule: the decision on whether data can leave its environment must be made before the request is sent, not after a response comes back.

3. Capability gate

What actions can the model trigger? The permissions of read-only tools must be tiered separately from those of write, outbound, and system tools. High-risk actions require human confirmation or dual approval.

4. Evidence gate

Is every invocation traceable? Audit records must cover:

• The request fingerprint
• The model version
• The policy rules that matched
• The resulting decision
• The operator involved

And audit logs must be stored separately from business logs, under independent permissions, and must not be editable by the application layer.

Without any one of the four gates, “refusing to hand over control” is just a statement, not a capability.

3. Policy as Code: Make Red Lines Reviewable, Testable, and Reversible

A red line that exists only in a document effectively does not exist. A practical approach is to externalize policies as declarative configuration and deploy them separately from business code.

{
  "policy_id": "llm-inference-guard-v1",
  "scope": ["agent.tool_call", "model.invoke"],
  "deny": [
    { "class": "autonomous_weapon_control", "rule": "non_negotiable" },
    { "class": "bulk_pii_export",          "rule": "non_negotiable" },
    { "class": "exec_privileged_shell",    "rule": "requires_dual_approval" }
  ],
  "allow": [
    { "tool": "search_internal_doc",  "require": ["role in {analyst, engineer}"] },
    { "tool": "submit_model_ticket",  "require": ["rate_limit: 10/min"] }
  ],
  "default": "deny_with_log",
  "audit": { "sink": "log_service", "tamper_proof": true, "retention_days": 180 }
}

The corresponding runtime check should be implemented as a single, unified interception layer rather than scattered across business branches:

class ActionGuard:
    """Every external action triggered by model output must pass through this guard."""
    def check(self, call: ToolCall, ctx: RequestContext) -> Verdict:
        v = self.policy.evaluate(call, ctx)      # Evaluate the call against the policy
        self.audit.write(                        # Persist evidence, stored separately from business logs
            request_id=ctx.id, model=ctx.model_version,
            policy_id=v.policy_id, matched=v.rules,
            decision=v.decision, actor=ctx.actor
        )
        if v.decision != "allow":
            raise PermissionDenied(v.reason)
        return v

Three key practices matter here:

• Deny by default: Actions that are not explicitly declared never make it onto the allowlist. This prevents “granting permissions after launch” from becoming the norm.
• Decouple policy from the model: Switching models, versions, or deployment regions does not change the policy. Policy changes go through independent review and a canary release.
• Layer red-line rules above business rules: Each team can adjust its own business policies, but red-line rules can only be modified by security or compliance roles, and every change must leave a trace.

4. Treating the Model as a Dependency: A Model Bill of Materials

In software engineering, a bill of materials (BOM) for dependencies is a basic practice. A large model is also an external dependency and needs an equivalent list:

Entry	What to record	Governance purpose
Source and license	Model source, license terms, commercial use and redistribution restrictions	Compliance review and legal confirmation
Version and weight fingerprint	Version number, weight hash, release channel	Supply chain integrity verification
Dependency chain	Inference framework, tokenizer, plugins, external retrieval sources	Vulnerability propagation and change-impact analysis
Deployment form	Public API call / dedicated instance / on-premises deployment	Data residency and data egress determination
Evaluation results	Red team results, known failure modes, capability boundary description	Risk tiering and admission decisions

The BOM must be machine-readable and integrated into the change management process: without version drift detection, you cannot explain changes in production behavior. Many “the model suddenly got dumber or more aggressive” incidents turn out to be caused simply by an upstream silent upgrade of the inference engine or default parameters.

It is also advisable to establish an admission process: before a new model or version goes live, it must pass red team testing matched to the intended scenarios, including jailbreaking, prompt injection, tool misuse, data leakage, and unauthorized actions. The results should be mapped to a risk level in the policy configuration, not left buried in an evaluation report.

5. The Data Plane: Classification, Redaction, and Residency

• Classification: Divide data into four levels: public, internal, sensitive, and restricted. For each level, define which model invocation patterns and regions are allowed to access it.
• Redact before sending: Perform field-level identification and replacement in the client-side SDK or at the unified gateway to reduce the chance that sensitive information enters the context. Do not rely on filtering on the model side.
• Residency constraints: Restricted data may only be processed on private or dedicated resources. Cross-region calls should be blocked directly at the policy layer, not left to network ACLs.
• Minimal logging: By default, logs and monitoring that capture prompts should apply redaction and use short retention periods. Samples that need to be kept longer for auditing must be requested separately and stored encrypted.
• Caching and memory: Session memory and vector retrieval indexes are also data landing points. They must be included in the same lifecycle management; otherwise, deletion requests cannot truly take effect.

6. Kill Switches and Degradation Paths

The most concrete test of “control” is this: can you shut down a capability chain within minutes while keeping the business running?

Design three tiers of circuit breakers in advance:

1. Policy circuit breaker: Take a class of action or a tool offline through the configuration center, without a new release.
2. Route degradation: When the primary model is unavailable or a call fails the policy check, switch to a capability-restricted model, a rule engine, or a human process.
3. Full-chain termination: Preset a “kill switch” that disables all external action capabilities of a given agent with one action, leaving only read-only Q&A.

Define a rollback drill mechanism as well. Circuit breaker switches must be drilled regularly. Otherwise, when you actually need them, you may discover that the configuration does not match the real permissions.

7. Organizational and Contractual Measures

Technical controls cannot replace organizational arrangements.

At the project level, define:

• Clauses limiting the scope of model use
• Audit cooperation obligations
• Change notification obligations
• Security incident response time limits

At the organizational level, define:

• Who owns model use request and approval
• Who has final authority over red-line decisions
• Who owns post-incident traceability

Responsibility cannot be outsourced to the model supplier along with the purchase. When something goes wrong, only the user can produce audit evidence, execute circuit breakers, and explain how the incident was handled.

8. Go-Live Implementation Checklist

1. Is there a machine-readable model BOM that can be compared against the versions actually deployed in each environment?
2. Do all external actions pass through a unified interception layer with deny by default?
3. Are audit logs stored separately with independent permissions, tamper-proof, and kept for a defined retention period?
4. Does sensitive data redaction happen before the request is sent?
5. Are circuit breaker switches configurable, and is there a drill record from the last three months?
6. Do model or dependency version changes trigger regression testing and risk reassessment?
7. Are there any “shadow invocations” that bypass the gateway, such as scripts connecting directly or temporary scripts with hardcoded credentials?

9. Common Pitfalls

• Mistaking filtering for governance: Content filtering only reduces output risk. It does not address sensitive data leaving its environment on the input side, or unauthorized actions.
• Mistaking a contract for a control: The enforceability of usage terms depends on technical constraints. Without them, there is no way to verify that the other party is complying.
• Mistaking evaluation for admission: One-off evaluation results become outdated as models are updated, so continuous regression testing is required.
• Mistaking logs for audit: Application-layer code can modify business logs, so they do not meet the non-repudiation requirements of an audit.
• Governing only production: Test, staging, and offline batch processing environments are often the easiest paths for data leakage and unauthorized calls.

Conclusion

The controversy over supply chain risk determinations does not change the technical team’s situation: a model’s permission boundaries are ultimately decided by its architecture, not by declarations. The four gates (identity, data, capability, and evidence), together with policy as code, a model bill of materials, and a testable kill switch, form the minimal engineering implementation of “refusing to hand over control.” If you plan to build this control system on a mature cloud platform such as Baidu AI Cloud, using general capabilities like object storage, logging, monitoring and alerting, and dedicated resources, fold these governance rules into architecture reviews and go-live checklists. Do not leave them to be patched after launch.