13.3 Supply-Chain Traceability
13.3.1 Pain Points in Supply-Chain Scenarios and the Value of Blockchain
A bottle of wine passes from the production region to the table through many stages: vinification, bottling, export, ocean shipping, distribution, retail. Every stage can become a point where information breaks: a wine merchant can falsify the vintage, a middleman may pass inferior goods off as quality products, and logistics data may be tampered with. The root cause is that each participant maintains its own isolated database, with no trusted shared layer. When a product's origin must be traced, coordination costs are enormous and the results are hard to credit. This is the typical symptom of a broken chain of trust in the supply chain.
When supply-chain participants are unwilling to trust a database maintained by any single organization, or when cross-organizational audits require joint witnessing, the governance cost of a single center rises. This does not mean that a centralized database is technically "incapable." Blockchain offers one optional path: multiple governing parties jointly maintain an append-only record, using consensus, signatures, and hashes to make later tampering more detectable. If the parties already have a trusted regulator, signed logs, and a mature data-exchange platform, a conventional architecture may be simpler and less costly.
Representative early food-traceability pilots chose a permissioned-blockchain architecture. IBM Food Trust, a collaboration between IBM and retailers such as Walmart, represented key farm-to-store events — harvest time, processing temperature, logistics route, and storage conditions — in a jointly governed ledger. Traditional tracing may require coordinating multiple stages one by one; when data is complete, identifiers are consistent, and the query path is available, a shared ledger can shorten retrieval time. What consumers see at the point of sale is still an application view assembled from authorized data, not physical truth automatically proved by a blockchain. The real engineering challenge lies in the trustworthiness of "first-mile" data, a boundary we will return to shortly.
Counterfeit and substandard goods are another chronic problem. Physical anti-counterfeit labels can be copied, and centralized lookup databases can be attacked. A ledger offers a path that multiple parties can verify jointly: bind a verifiable identifier to an item or batch, then have accountable parties sign and submit key transfers. Consumers can check whether an identifier matches the registered transfer history. Whether that reduces counterfeiting still depends on clone-resistant physical labels, key protection, and field inspection.
One common misconception needs clarifying here: blockchain cannot guarantee the truth of data before it goes on chain, nor can it provide absolute immutability in the mathematical sense. Under defined assumptions about consensus, key security, and node governance, it can make historical rewriting harder and easier to detect. A farm worker may still overstate a hog count, and a private key may be stolen. Device roots of trust, calibration, signatures, spot checks, and anomaly detection can strengthen source evidence, but each has its own failure boundary. An on-chain record provides verifiable evidence, not an automatically true fact or an automatic legal conclusion of non-repudiation.
Case: Pork Traceability from Farm to Table
A simplified supply chain: Farm A, Slaughterhouse B, Logistics Company C, Supermarket D. Each stage is equipped with IoT devices.
- Hogs leave the farm: each hog wears an RFID (radio-frequency identification) ear tag recording date of birth, feed batch, vaccinations, and more. This information, together with the hash of the quarantine certificate, is written to the blockchain.
- Slaughter and cutting: the RFID is scanned to confirm identity; the cut pieces of meat receive new RFID tags linked to the original information, recording slaughter time, cutting batch, and quality-inspection results.
- Cold-chain transport: the time is recorded when the refrigerated truck is loaded, and temperature sensors report data every few minutes. The edge gateway computes means and extremes, placing only the hash fingerprint and abnormal events (such as a temperature excursion) on chain. When the threshold is exceeded, a smart contract automatically triggers an alert.
- Shelving and sale: the supermarket's refrigerated case scans the RFID to confirm the batch and synchronizes on-chain information. Consumers can scan the QR code on the package and see the complete path: release-from-farm time, slaughter date, logistics temperature curve, arrival time at the store.
If a food-safety problem arises, regulators can search related batches and events by a common identifier and narrow the investigation. Compared with "calling level by level and checking paper records," this can shorten trace time. The actual improvement depends on data coverage, identifier mapping, index performance, and timely truthful submissions; without acceptance data, an "order-of-magnitude" gain must not be assumed.
This scenario illustrates a role blockchain may play: it does not replace the IoT, but provides a jointly witnessed record layer across organizational boundaries. Source data still depends on sensor calibration, device identity, and business verification. Before choosing a ledger, compare its governance, throughput, privacy, and operational costs with those of centralized signed logs, third-party evidence preservation, and regulatory platforms. Blockchain must not be assumed to be the "most mature" solution in every case.
13.3.2 Architecture of a Blockchain-Based Traceability System
In designing an IoT traceability system, the core is not which blockchain platform or which sensor model to choose, but clarifying the participants' roles, the paths along which data flows, and the stages where smart contracts intervene. Once this architecture descends into tangled coupling, both later maintenance costs and data credibility are sharply diminished.
Participants and Role Division
In a typical supply-chain traceability system, the participants fall into four roles, each with clearly defined data responsibilities and permission boundaries.
- Producers: farms, processing plants, wineries, and the like. They deploy environmental sensors (temperature, humidity, light) or product-identification readers (RFID, QR codes) and record production information — planting batch, harvest time, quality-inspection reports — on chain together with sensor readings. Producers are the source of the data and are responsible for its originality.
- Logistics providers: they carry products from the production site to the warehouse and on to the terminal. The refrigerated truck's temperature curve, loading and unloading timestamps, and door open/close records are all collected automatically by the vehicle-mounted edge gateway and put on chain. The key constraint is that a logistics provider signs only the data it generates itself and cannot tamper with the original records uploaded by producers.
- Sellers and retailers: they receive and verify the batch data pushed from upstream stages while recording warehouse-inbound order numbers, storage conditions, and time of sale. The point of sale is often where consumers begin querying information, and it is also the last link of the traceability loop.
- Regulators or certifiers: they do not participate directly in transactions but hold read-only access to network-wide data and can verify any single record. In some deployments, the regulator also acts as an ordering node or endorsing node in the blockchain network, strengthening the system's public credibility and preventing any single participant from monopolizing consensus.
These four roles are business boundaries rather than mandatory deployment units. Whether every role operates its own peer nodes depends on governance and operational capability; a trusted operator may host nodes on a party's behalf. Identity, policy, chaincode, channels, and private data collections jointly enforce write, endorsement, and query boundaries, all subject to configuration, key security, and upgrade governance. No single mechanism should be treated as absolute isolation.
Layered System Architecture and Data Flow
The figure below shows a typical layered design. From the physical sensors at the bottom to the user interface at the top, each layer's responsibilities are clearly bounded, and data flows between layers according to fixed rules.
The core value of layered design is decoupling. When a higher-precision temperature sensor must be swapped in, only the data-parsing firmware in the edge layer needs updating; when a smart contract's business logic must change, only the application chaincode in the blockchain network layer is updated, and the other layers stay untouched. This loose coupling gives the system the ability to evolve over a long life cycle — IoT devices often run for 5–10 years while business rules may be adjusted every year, and the layered architecture narrows the blast radius of each upgrade.
Smart-Contract Logic and the Automatic Alert Mechanism
In traceability scenarios, a smart contract can do more than record: it can execute deterministic rules over submitted transactions and make rule versions and results easier for multiple parties to verify. It does not guarantee truthful input or delivery of an off-chain notification or physical action. The following simplified cold-chain monitoring contract shows the core logic; an actual deployment must adapt it to the selected chain language, permissions, and execution environment.
// pseudocode: ColdChainMonitor contract
// a conceptual model based on Hyperledger Fabric chaincode (Go/Node.js), not runnable code
// struct BatchRecord
// dataHash: bytes32 // hash of sensor data, for integrity verification
// timestamp: uint256 // time the data was uploaded
// productId: string // product batch number
// alertFlag: bool // alert flag
// constant TEMP_THRESHOLD: int = 4 // example threshold: 4°C
// event Alert
// productId: string
// timestamp: uint256
// reason: string
// function submitData( productId: string, temperature: uint256, dataHash: bytes32 )
// 1. compute key = hash(productId + timestamp)
// 2. set alertFlag = (temperature > TEMP_THRESHOLD)
// 3. store records[key] = BatchRecord(dataHash, now, productId, alertFlag)
// 4. if alertFlag is true, emit the Alert event
// return: boolean (true)
// function verify( key: bytes32, claimedHash: bytes32 ) — read-only function
// 1. read dataHash from records
// 2. return (dataHash == claimedHash)The contract demonstrates two key steps: submitData emits an Alert event when the submitted value exceeds the threshold, and subscribers such as logistics consoles and regulatory platforms receive, retry, and escalate it off chain. An event commit does not mean notification delivery, nor does it prove the measurement true. Contract code and its version are governed by the network. Whether it is upgradeable, who approves an upgrade, and how old versions remain traceable depend on platform policy and permissions, not a generic claim of "network-wide consensus."
In production, a smart contract can carry more complex logic — for example, changing a batch to "pending review" after two consecutive excursions, after which an off-chain business service blocks release until a human approves it. Centralized systems can also automate alerts and audits with rule engines, signed logs, WORM storage, and separation of duties. A permissioned ledger adds value when independent organizations need to witness rule versions and state changes jointly; the distinction is not that a centralized database "cannot automate."
One thing to be clear about here is the language choice for this chapter's examples. The contract code earlier in this chapter is mostly written in Ethereum-style Solidity — not to imply that traceability systems should all be built on Ethereum, but because Solidity has the most complete documentation and tooling, which makes it the clearest way to explain contract logic itself. Traceability networks deployed in industry more often run on consortium-chain platforms such as Hyperledger Fabric and FISCO BCOS: Fabric calls its contracts chaincode, and the same cold-chain alert logic written in Go has roughly this skeleton —
// Cold-chain alert chaincode skeleton (Hyperledger Fabric, Go, illustrative)
func (c *ColdChainContract) SubmitData(ctx contractapi.TransactionContextInterface,
productID string, temperature float64, dataHash string) error {
alert := temperature > 4 // threshold check, identical to the Solidity version
ts, _ := ctx.GetStub().GetTxTimestamp()
record, _ := json.Marshal(BatchRecord{DataHash: dataHash, Timestamp: ts.Seconds, Alert: alert})
return ctx.GetStub().PutState("batch/"+productID, record) // write to the channel's world state
}The chaincode writes state into the channel's world state, and the endorsement policy determines whether a transaction can be accepted — for example, by requiring signatures from both producer and logistics organizations. Channels or private data collections can further constrain visibility. In the Chinese industrial context, FISCO BCOS is one domestic consortium-ledger option worth evaluating. Whichever platform you choose, Section 13.2's "on-chain fingerprint, off-chain storage" idea can be a common starting point, but contract logic cannot be assumed to migrate equivalently. Transaction finality, identity, endorsement, privacy, event-delivery, and upgrade semantics must each be redesigned and verified.
Engineering Trade-off: Full Data vs. Hash on Chain
A common decision point: should the sensor's complete readings (say, a temperature record every 5 seconds) all be written to the chain? The cost is extremely high. IoT scenarios involve large device counts and high data-generation rates; putting everything on chain rapidly bloats the ledger and drags down consensus performance. The standard pattern in engineering practice is "on-chain fingerprint, off-chain storage."
- Off-chain storage: raw data stays in the edge gateway's local database or in decentralized storage such as IPFS (InterPlanetary File System).
- On-chain fingerprint: only the data's hash (e.g., SHA-256, 32 bytes), the digital signature, and a small amount of metadata (product ID, timestamp) are written to the blockchain.
The core logic is to obtain the original artifact, recompute its hash, and compare it with the ledger commitment to determine whether the current bytes match what was submitted. A match proves neither truthful capture, completeness, nor an accurate timestamp; a mismatch must first rule out encoding, version, and file-boundary differences. This pattern can reduce on-chain storage pressure, but off-chain replicas, retention, access, deletion, and forensic procedures still need explicit design. Whether to use it depends on data volume, audit objectives, and cost; it is not the only inevitable deployment pattern.
Deployment Choice: The Trade-off Between Permissioned and Public Chains
Supply-chain projects often evaluate permissioned ledgers because their governors can define organizational admission, endorsement, read/write rights, and operational responsibility. Raft commonly provides crash-fault-tolerant ordering, whereas PBFT-family protocols address Byzantine assumptions; their names are not interchangeable labels. A permissioned ledger is not automatically faster or more private than a public one. Node topology, consensus settings, channels or private collections, key management, and load tests must establish those properties.
In industrial-grade supply-chain scenarios, the permissioned chain is the mainstream choice. In the supply-chain application of the "decentralized distributed shared ledger" described in the research literature, for example, the consensus nodes are usually controlled jointly by the core participants, in exchange for higher transaction throughput and data privacy. This architecture gives up the public chain's complete openness but gains controllable trust that maps one-to-one onto business roles. Designers need to settle this trade-off with all participants early in the project and assess whether the full transparency of a public chain is needed — in scenarios that require public verification by consumers, such as food safety, selected data (such as product-certification hashes) can be published to a public chain as an anchor, realizing a two-tier structure of "intranet permissioned chain + extranet public chain."
Engineering Checklist for This Section
When building a traceability system, designers must at least confirm the following questions:
- [ ] Are the participants' roles clearly defined, and is there a third-party regulatory node?
- [ ] Can the edge gateway hash and sign sensor data?
- [ ] Does the smart contract define quality-inspection logic and alert rules? Do the thresholds need dynamic configuration?
- [ ] Is raw data kept off chain, with only hashes and metadata stored on chain?
- [ ] Was a permissioned ledger or another architecture selected from participant admission, fault assumptions, and data-visibility needs, with performance and privacy boundaries measured?
- [ ] Does the application layer's data-query interface support fast indexing by product ID and time range?
- [ ] Do validator, orderer, or endorsing-node counts satisfy the selected protocol's fault-tolerance and quorum rules, while spanning independent governance roles?
A blockchain-based traceability system essentially shifts part of the trust placed in a single database administrator onto consensus rules, node governance, keys, and contracts. Its engineering implementation is more than writing smart contracts: on-chain timing, data formats, the signing workflow, node count, error correction, and privacy all require trade-offs. The discussion below examines how AI and fog-computing nodes can improve real-time processing while preserving verifiable evidence.
13.3.3 Privacy-Protection Schemes for Traceability Data
Blockchain's openness and transparency give supply-chain traceability a foundation of data consistency, but that very openness stands in direct conflict with commercial privacy. A complete traceability system involves many participants — raw-material suppliers, manufacturers, logistics providers, distributors, retailers, even end consumers. Sensitive information such as production batch numbers, supplier names, purchase prices, and customer orders lies fully exposed under the "anyone can query" full-ledger replication model. Fully public on-chain data is unacceptable in a competitive business environment.
The design of a privacy-protection scheme is therefore not an optional embellishment but the threshold that decides whether a traceability system can be deployed at all. Three technical routes are mainstream today: zero-knowledge proofs, attribute-based encryption, and the channel mechanism.
Zero-knowledge proof (ZKP) allows a prover to present a verifier with evidence that an assertion is true, while the verifier learns nothing beyond it. A logistics node that must prove a shipment's temperature never exceeded 4 °C, for example, can present a ZKP to the regulator without revealing a single raw temperature value, and the regulator confirms compliance simply by verifying the proof. zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) are the most mature ZKP implementation and were first put into production by the Zcash cryptocurrency project. In supply-chain scenarios, ZKPs suit situations where conditions must be verified frequently (shelf life, geofencing) yet the specific values must not be exposed. The cost is the heavy computation required to generate proofs — unfriendly to IoT terminals (RFID-tag-class devices) — so the proof computation usually has to be done on an edge gateway or relay node.
Attribute-based encryption (ABE) embeds the access-control policy into the encryption process itself. The sender encrypts data with a set of attributes (for example, "role = regulator AND region = East China"), and only receivers holding a private key that satisfies the policy can decrypt. ABE supports fine-grained one-to-many encryption, a good fit for the traceability requirement that "some data is visible only to specified roles." A producer, for example, can encrypt purchase prices with ABE so that only the supplier's own private key can decrypt them, while a logistics provider holding the encrypted data still cannot read it. ABE's theoretical framework is well developed, but key distribution and management are complex in actual deployment.
Channels and private data collections must be distinguished. A Hyperledger Fabric Private Data Collection (PDC) lets a subset of organizations on one channel share private data. Plaintext is disseminated through gossip among peers authorized by the collection policy and stored in their private state databases; the ordering service and unauthorized organizations see only the hash committed to the channel ledger. That hash can show whether later-disclosed bytes match the earlier state, but it does not prove the content true. Deployments must also configure collection membership, endorsement, requiredPeerCount, maxPeerCount, cross-organization gossip, retention, and purge policies; otherwise even an authorized peer may lack the private data.
These three techniques each emphasize different aspects of privacy model, computational cost, and implementation complexity; Table 13-2 gives the key comparison:
Table 13-2 Comparison of Privacy-Protection Techniques
| Technique | How It Works | Strengths | Weaknesses | Applicable Scenarios |
|---|---|---|---|---|
| Zero-knowledge proof (ZKP) | The prover generates a mathematical proof; the verifier checks a defined assertion without receiving the witness data | Reduces disclosure of raw data; verification can be reproduced | Circuits, parameters, and implementations may still leak metadata; proof generation is costly | Compliance verification (temperature ranges, certificates of origin) |
| Attribute-based encryption (ABE) | Encrypted data is bound to an access policy; only private keys with matching attributes can decrypt | Fine-grained access control; one-to-many encryption | Complex key management; decryption performance is affected by policy size | Role-tiered data visibility (prices visible to suppliers, invisible to logistics providers) |
| Channel mechanism (Fabric PDC) | Data travels only between peers; only hashes are stored on chain | Relatively simple to implement; lightweight on-chain footprint | Tied to a specific blockchain platform; channel configuration is complex to manage | Protection of commercial transaction details (orders, quotations) |
In engineering practice, no single scheme covers every privacy need. Large supply-chain systems usually combine all three: the channel mechanism handles high-frequency commercial transactions, ABE controls the readable scope of sensitive data, and ZKP serves public verification by external regulators or consumers. When selecting, three dimensions deserve close evaluation: the compute threshold of IoT terminals (can a ZKP be generated on the terminal or at the nearest edge), the maturity of the key infrastructure (can ABE distribute keys securely without introducing a centralized KMS), and tolerance for platform lock-in (Fabric private data collections require the network to run on Fabric). The deciding factor in the end is engineering judgment grounded in the specific industry, the relationships among participants, and device capabilities. A practical way to start is to draw the data flows first — which data must be public (batch numbers, timestamps), which can be shared with some roles (quality-inspection reports), and which must be completely hidden (purchase prices) — then apply the matching technique layer by layer, rather than pursuing "whole-chain encryption" from the outset.
13.3.4 The Privacy-Computing Technology Landscape: From Cryptographic Primitives to Engineering Selection
ZKP and ABE are just two branches of the technology family known as "privacy computing." Privacy computing is not a single technique but a collection of technologies unified by one goal — "data usable but not visible": the use value of the data is preserved while the data itself is never exposed. This chapter has already touched two branches — 13.3.3 (ZKP/ABE, for verification of and access control over traceability data) and 13.5.2 (federated learning, for cross-party model training). Here we complete the panorama and provide a framework for engineering selection.
Federated Learning works on the principle of "the data stays put, the model moves": participants train locally and exchange only model parameters or gradients. 13.5.2 already discusses its integration with blockchain in detail (parameter hashes on chain, incentive governance, gradient compression) and will not be expanded here. The boundary worth emphasizing: federated learning's default threat model assumes an "honest but curious" aggregator, and the parameters themselves may still leak information about the training data — differential privacy or secure aggregation must be layered on top for substantive protection.
Differential Privacy (DP) injects mathematically quantifiable noise into query results or training gradients, so that the addition or removal of any single record has a provably bounded effect on the output distribution. Its sweet spot is statistical queries and population profiling: for example, cross-factory statistics on equipment failure-rate distributions or cross-fleet energy-consumption profiles — the report can be shared without any single device's readings being reconstructable. The cost is precision loss: the noise budget (epsilon/delta) trades off against statistical utility, and with small samples the noise may drown the signal. Differential privacy therefore fits "population-oriented" analytics, not "single-point-oriented" control: nobody adds Laplace noise to a control command and then uses it to set a valve opening.
Secure Multi-Party Computation (MPC) lets multiple parties jointly compute an agreed function without revealing their individual inputs, based on cryptographic constructions such as secret sharing and garbled circuits. It has the weakest trust assumptions (no reliance on any third party or hardware) and its security is cryptographically proven. The cost is many communication rounds and heavy compute overhead — participants must interact over multiple rounds, with computation amplified by orders of magnitude relative to plaintext. In IoT, MPC is mostly used for low-frequency, high-value joint computations such as multi-party risk control or joint pricing, not real-time control loops; putting MPC into a millisecond-level control path is unrealistic under current compute conditions.
A Trusted Execution Environment (TEE) uses hardware isolation to reduce the host operating system's ability to read enclave code and data. Its protection depends on the specific TEE, memory encryption, attestation, and physical-attack model. Runtime overhead is often below that of general MPC or homomorphic computation, but enclave transitions, protected-memory limits, and I/O still require measurement. Intel SGX and ARM TrustZone can protect models or keys during edge inference; the host can still observe some metadata, and outputs may leak information. The chip vendor, manufacturing supply chain, firmware, side channels, and remote-attestation service all enter the trust boundary. A TEE therefore narrows the trusted computing base rather than providing absolute isolation.
Homomorphic Encryption (HE) allows computation directly on ciphertext, with decryption yielding the same result as computing on plaintext. Fully homomorphic encryption (FHE) can in theory support arbitrary operations, but its performance is still far from engineering practicality — ciphertext operations cost orders of magnitude more than plaintext, and ciphertext expansion is severe. Partially homomorphic schemes (such as Paillier's additive homomorphism) have already been deployed in specific aggregation scenarios: multiple reporting devices each encrypt their readings, the aggregator sums over the ciphertexts, and only the final total is decrypted. Within any foreseeable IoT engineering horizon, homomorphic encryption should be treated as a supplementary option for specific aggregation operators, not a general-purpose solution.
Table 13-3 positions the five technology families:
Table 13-3 Engineering comparison of the main privacy-computing technology routes
| Technology | What is protected | Performance overhead | Maturity | Typical IoT scenarios | Main limitations |
|---|---|---|---|---|---|
| Federated learning | Training data never leaves the local site | Medium (mostly communication) | Under engineering rollout | Cross-enterprise joint failure-prediction models | Parameters may still leak information; needs DP/secure aggregation on top |
| Differential privacy | No single record is identifiable | Low | Fairly mature | Device population profiling, statistical reports | Precision loss; unsuitable for single-point control |
| Secure multi-party computation (MPC) | Each party's inputs | High (many communication rounds) | Usable in specific scenarios | Multi-party joint risk control, joint pricing | Compute and communication amplification; cannot enter real-time control paths |
| Trusted execution environment (TEE) | Code and data at runtime | Low (near-native) | Commercially mature | Model-inference protection at edge nodes | Requires trusting the chip vendor; history of side-channel attacks |
| Homomorphic encryption (HE) | Computation stays encrypted end to end | Extremely high (FHE) | Early stage | Encrypted aggregation (specific operators such as summation) | Fully homomorphic still far from practical; ciphertext expansion |
Selection can follow a decision path along four dimensions. First, how rigid is the data-residency requirement: for compliance-driven statistics alone, differential privacy is usually the most economical; only when data-sovereignty clauses demand physical non-egress do you need federated learning or MPC-grade schemes. Second, the number of participants: for high-frequency collaboration among two or three parties, TEE or a channel mechanism suffices; with many mutually distrusting participants, MPC's communication overhead worsens with participant count, and federated learning plus secure aggregation is a more feasible backbone. Third, latency requirements: in real-time control loops only TEE fits (or nothing at all); federated learning, MPC, and homomorphic encryption belong to training and offline analysis. Fourth, the compute budget: on MCU-class terminals almost every cryptographic scheme must be proxied by an edge gateway; only gateway-class compute can entertain ZKP proof generation and encrypted aggregation.
One common confusion deserves clarification: privacy computing and blockchain are complementary, not substitutes. Blockchain (including on-chain attestation and ZKP verification) answers "process trust" — that some data was indeed submitted by some identity at some time and has not been tampered with since; privacy computing answers "data usable but not visible" — collaborators can use the data's value without obtaining the raw data. On-chain attestation verifies the "process," privacy computing protects "the data itself," and only together do they form the complete trust chain for cross-organizational data collaboration: in the words of 13.5.2, federated learning decides "whether you may use someone else's data," while DID and blockchain decide "whether you can trust the counterparty's identity and records."
Returning to this chapter's main thread. In cross-organizational AI-agent collaboration, privacy computing and DID/blockchain each hold one segment of the trust chain: the former delimits the boundary of data-usage rights, the latter provides verifiability of identity and records. But no matter which privacy-computing scheme is adopted, none of them changes the deterministic constraint framework governing AI control of physical devices — permissions, confirmation, and audit (Chapters 7 and 8) remain the non-negotiable bottom line. Privacy computing protects "how data is used," not "whether control commands need authorization"; a model, however much noise was added, still emits commands that must travel the existing permission and audit channels. Confusing the two mistakes "data privacy" for "behavioral safety."