Section One
AI integration is already underway, with AI capability is outrunning the structure to hold it
On August 26, 2026, Salesforce and Anthropic announced a partnership under which Salesforce customer relationship data becomes directly accessible to an AI assistant, and Claude becomes the reasoning model inside Salesforce's own agent platform. The connection is made through what is called a Model Context Protocol server. Access is scoped to the permissions of the individual user. As one Salesforce executive described it: if a user does not have permission to see a record, the connection does not have permission either.1
That announcement is one product from two companies. It is not, by itself, the subject of this paper. What matters is the category it represents, because the same architecture is arriving across every major enterprise software platform your organization already runs. Product lifecycle management. Enterprise resource planning. Manufacturing execution. Quality management. Document control. Each of these vendors is building, or has already built, the same kind of connection.
The capability on offer is substantial and it is worth being specific about it. An agent with structured access to your manufacturing and quality systems can do work that no specialist organization currently has the engineering hours to do: correlate scrap and rework causes across years of production rather than across the last quarter, surface the process windows where your first-pass yield actually lives, connect tool life against material lot against machine against operator, and answer in minutes questions that today require a week of someone's time and therefore never get asked. For an organization whose constraint is senior engineering hours (which is every organization in this field) that is not a marginal efficiency. It is capacity.
What has not arrived alongside the capability is the structure to hold it. The decision in front of engineering leadership is not whether to buy one specific product. It is a structural decision that will be made once and then repeated a dozen times over the next two years, each time with less deliberation than the first. The decision is this: which of your systems of record are AI agents permitted to reach, under whose authority, with what ability to act, what may they retain, and with what evidence trail behind them.
That line, between what an agent may reach and what it may not, is the trust boundary. Drawn carelessly it puts client intellectual property at risk. Drawn deliberately it does something more useful: it defines the space inside which an organization can deploy this capability aggressively, at speed, and demonstrate to its clients exactly why doing so is safe.
This paper is about drawing that line in an organization whose commercial value rests on intellectual property that is frequently not its own, and whose clients are frequently competitors with one another. The argument is not that the boundary limits what you can build. It is that the boundary is what makes building possible.
Section Two
The permission model that lets you say yes: read, write, execute
Established
For the past three years, the governing question about AI in engineering organizations has been a question about disclosure. Does confidential information leave the building when an engineer uses a chat interface? The concern was well founded. In 2023, engineers at Samsung Semiconductor pasted proprietary source code and internal meeting content into a public chat assistant on at least three separate occasions within a twenty-day period, and the company subsequently restricted employee use of such tools.2 The organizational response across most of industry followed the same shape: policy, training, and a private or contractually protected deployment.
That response addressed a real problem, and for a chat interface it was sufficient. The model saw what a person chose to paste into it, and nothing else. It is also the reason many organizations are still holding this technology at arm's length: the only control they know is refusal, and refusal is expensive.
An agent connected to a system of record is a different object, and it admits far better controls than refusal. It does not wait to be handed information. It retrieves information on its own initiative, in response to an instruction, from systems it holds standing credentials to reach. In many configurations it also writes: it updates a record, closes an item, sends a message, creates a document. The unit of governance is therefore no longer a paste operation performed by a person who must be trained not to. It is a permission set, which is a thing an engineering organization already knows how to specify, review, and audit.
The model you already know
The useful thing about this problem is that the correct mental model for it is more than fifty years old, and most engineers already understand it well.
The UNIX operating system, in its fourth edition in 1973, established a permission model that has survived essentially unchanged into every POSIX system running today. Access to a resource is not a single condition. It is three independent bits: r for read, w for write, x for execute. Those three bits are then specified separately for three classes of accessor: the owner, the group, and everyone else. Nine bits in total, conventionally written as an octal number, where read carries a value of four, write a value of two, and execute a value of one.5
The design insight embedded in that scheme is the one this paper is about. Reading a resource and modifying a resource are different privileges with different consequences. A system that can distinguish between them can grant the first generously while withholding the second. This is precisely the arrangement that lets an organization deploy a capable tool without accepting an unbounded risk.
Why this matters commercially, not just technically
Most AI integrations reaching the market in 2026 are procured, discussed, and approved on the basis of a single bit: connected, or not connected. The vendor demonstration shows the assistant retrieving a record and then updating it, in one continuous motion, as though these were the same operation. The approval covers both because nobody separated them in the conversation.
The organization that separates them gets something the organization that does not cannot have: the ability to say yes. A read-only agent across your quality history, your process data, and your production records carries a bounded and describable risk, and it delivers most of the analytical value available in the first year. An organization that has not made the distinction faces an all-or-nothing decision, and prudent leadership in that position correctly says no — and forfeits the capability.
Measured against a permission model that has been standard practice since 1973, treating access as a single bit is a regression. It is also, and more importantly, the reason a great deal of available value is currently sitting unclaimed.
Applied to an agent, the three bits translate directly, and they are the three questions that define a trust boundary:
Read - Reach
Which systems, and which records inside those systems, can the agent retrieve? This is the question most vendors answer, and they answer it well. Permission inheritance — the agent operates under the credentials and role of the individual user — is now the standard architecture and it is a sound one. This is also the privilege to grant generously wherever the underlying data is your own, because it is where the analytical value lives.
Write - Action
What can the agent change, send, publish, or delete? This question is answered far less often and far less clearly. An agent that can only read has a bounded failure mode. An agent that can write, transmit, or publish has a failure mode bounded only by what its credentials permit. In a UNIX file system these two privileges are separated by a single bit. In most AI integration proposals they are not separated at all, and separating them is the highest-value hour of work in the entire evaluation.
Execute - Invocation and evidence
Which tools and operations can the agent invoke on its own initiative, and afterward, can you demonstrate exactly which records it touched, on whose instruction, and what it did with them? An agent's ability to chain one tool into another is where the largest failures originate. It is also, handled well, where your evidence comes from- the record that lets you demonstrate compliance to a client rather than assert it.
The third class in the UNIX model - owner, group, other - matters here as well, and it is the part most often discarded. The model does not grant a single organization-wide permission set. It grants different permissions to different classes of accessor over the same resource. The equivalent question for an agent is whether it holds one set of permissions across your entire organization, or a different set per program, per client, and per data class. Sections Four and Five show why that distinction is not a limitation but the mechanism that lets you pool your most valuable data safely.
None of this is novel security thinking. The principle at issue was named in 1975 by Saltzer and Schroeder, in the paper that still supplies the vocabulary for the field: least privilege, under which every program and every user operates using the least set of privileges necessary to complete the job.6 The security community has simply had to restate it. In the 2026 revision of the OWASP Top 10 for Large Language Model Applications, published in August 2026, the risk category called Excessive Agency (a system's capacity to take consequential actions beyond what was intende) moved from tenth position to third, the largest single movement in the list.3 The stated rationale is direct: AI systems now hold access to tools, application programming interfaces, and business systems, and the security model must extend beyond model behavior to encompass what the system is permitted to do.4
Section Three
Building the guardrails that let an agent do real work
Established
Guardrails have a reputation problem. They are discussed as though they were a tax on capability, something bolted on afterward that makes a useful tool less useful. In practice the relationship runs the other way. Guardrails are what allow an organization to grant an agent meaningful access to meaningful systems. Without them the only safe configuration is a trivial one, and the value stays on the table.
To build them well, one property of these systems has to be understood precisely.
The most common assurance offered during an AI integration discussion is permission inheritance. The agent can only reach what the user can reach. This is true, it is important, and it should be a hard requirement of any integration you accept. It is not a complete control, and the reason is the single most important technical point in this paper.
Permission inheritance protects against an agent reaching records the user is not entitled to see. It does not protect against an agent taking records the user is entitled to see and moving them somewhere they should not go. Both operations are, from the permission system's point of view, fully authorized.
In May 2025, security researchers documented this precisely. An attacker filed an ordinary issue in a public GitHub repository. The issue text contained instructions addressed to any AI agent that might read it. When the legitimate user later asked their agent to review open issues in that public repository, the agent read the attacker's instructions along with everything else, followed them, retrieved data from the user's private repositories, and published that data into a public pull request.7
Every step was performed with the user's own credentials. Every step was authorized. The researchers were explicit that this was not a defect in the integration's code but an architectural property of the arrangement, and that the platform vendor could not resolve it through server-side changes alone.7
This class of attack is called indirect prompt injection, and it requires only that untrusted text reach the agent's working context. Untrusted text enters a manufacturing organization constantly: supplier quotations, client requirement documents, non-conformance reports filed through a portal, incoming email, specification revisions received as attachments, field service reports.
What a guardrail is, and what it is not
The word guardrail appears in nearly every vendor conversation and almost never carries a definition. In practice it describes two entirely different things, and the difference determines whether you have a control or a hope.
A guardrail that lives inside the model is not a control. Instructing the model to refuse certain requests, telling it in a system prompt to keep client programs separate, or relying on its training to recognize a malicious instruction — these are behavioral tendencies. They fail probabilistically rather than deterministically, they cannot be audited, and they degrade under exactly the conditions in which you need them. The 2026 OWASP guidance is explicit: build on the assumption that the model will be deceived, and concentrate effort on limiting what the agent can reach and change when that happens.4
A guardrail that lives outside the model is a control. It is a deterministic mechanism, implemented in ordinary software, that evaluates a proposed action against a policy and permits or blocks it, without consulting the model and without the model being able to influence the decision. The seven layers below are what the term should mean in a procurement conversation. Ask for them by name.
1. Scope limitation- the permission set itself
The narrowest set of systems, records, and operations the agent needs for its defined job, granted per program and per data class rather than organization-wide. This is least privilege applied directly, and it is the layer with the highest return for the least effort. Everything below supplements it; nothing below substitutes for it.
2. Deterministic policy enforcement at the point of action
A rule engine sitting between the agent and the system of record, evaluating every proposed operation against fixed policy before it executes. Not the model deciding whether an action is appropriate — a separate component the model cannot argue with. The policy should be expressible in ordinary language and readable by a non-specialist: this agent may not write to any record in the released state; this agent may not send outbound email; this agent may not read from Program A and Program B in the same session.
This layer is worth more than its security function alone. A written, enforced, machine-readable policy is a document you can hand a client. It converts an assurance into evidence.
3. Provenance tracking- knowing which content is untrusted
The most technically substantial defense, and the one that shows where this field is going. Content entering the agent's context is tagged with its origin, and content originating outside your trust boundary is permanently marked untrusted. Untrusted content may be summarized or reasoned about, but it is structurally prevented from influencing which tools the agent invokes or where data is sent.
A research team including authors from Google DeepMind and ETH Zurich published a working implementation of this approach in 2025, under the name CaMeL. The design separates the control flow of an agent's task, derived only from the trusted user instruction, from the data the agent handles, so that untrusted retrieved data cannot alter program behavior. A capability-based mechanism then constrains where data may flow. The paper reports provable security guarantees against a standard benchmark of injection attacks.9
This is not yet a feature you can specify in a purchase order from a mainstream enterprise vendor. It is a reasonable question to put to one: how do you distinguish trusted instruction from untrusted retrieved content, and what prevents the latter from directing the former?
4. Human confirmation on consequential actions
An explicit approval step before any operation that transmits, publishes, releases, or modifies a controlled record. This is the simplest control on the list and the one most often traded away during a pilot in the interest of demonstrating a smooth workflow. Resist that trade. A pilot that removes the confirmation step is not testing the configuration you intend to deploy.
5. Egress control — watching what leaves
Inspection of outbound content regardless of the agent's intent: what is being sent, to whom, and whether it contains classified or client-owned material. This is conventional data loss prevention applied to a new channel, and existing tooling largely works. What is required is recognizing that the agent constitutes a channel and configuring accordingly.
6. Architectural separation — two agents rather than one
Where an agent must both read untrusted external content and perform consequential actions, split the function. One configuration reads external content and can only produce text for a human to review. A second performs consequential operations and reads only from sources inside your controlled environment. Neither holds both privileges. This eliminates the specific configuration that every documented incident in this class has exploited.
7. Audit and retention
A durable, exportable record of every retrieval and every action: the user, the instruction, the records reached, the operation performed, the timestamp. Treated as a quality record, retained on a schedule consistent with your client agreements, and reviewable by a third party.
Guardrails cost capability, and that is a familiar trade
There is an honest trade here that vendors do not volunteer. In the CaMeL evaluation, the defended system completed 77 percent of benchmark tasks with provable security, against 84 percent for the same system undefended.9 Roughly a seven point reduction in task completion, purchased with a categorical improvement in security.
An engineering organization should recognize this shape immediately. It is the same trade as a torque specification, a hold point, or a first article inspection: throughput given up in exchange for a bounded failure mode. Nobody argues that a first article inspection makes a production line worthless. The correct response is not to look for a configuration with no cost; It is to decide deliberately how much capability to spend, on which systems, and to write that decision down.
Documented incidents across the past eighteen months reinforce the same conclusion: repository access exploited through injected issue text, messaging histories extracted through poisoned tool descriptions, a compromised integration package that silently copied every outbound email, and a multi-tenant isolation failure that exposed data across organizational boundaries.8 In each case the model behaved as designed. The containment was what failed — and containment is engineering, not luck.
Section Four
Protecting trust with your clients by identifying and enforcing barriers
The integrations now reaching the market were designed for a commercial sales organization. In that environment the data belongs to the company that holds it, the confidentiality obligations run in one direction, and the consequence of a disclosure is commercial embarrassment. None of those three conditions reliably holds in a specialized engineering supplier. The four conditions below are ordered by significance as they apply to motorsport and Tier-1 supply, and the first is the one that should govern your architecture.
Condition one: you serve competitors, and the trust between you is the asset
Established Practitioner position
A specialist supplier frequently holds programs with two or more directly competing teams or manufacturers at the same time. This is not an unfortunate side effect of a narrow market, instead it is the state of the market. There are only so many organizations in the world capable of producing a particular class of valve train component, composite structure, or transmission internal to the required standard, and the clients know it. Every one of those clients accepts the arrangement on a single condition: their design information does not reach the competitor down the road.
That confidence is not a minor compliance obligation sitting alongside the business. It is the business. A supplier that holds it is trusted with the work that matters, early, when the design is still fluid and the margin is still there. A supplier that loses it does not receive a corrective action request. It stops being invited to quote, by clients who never state the reason.
The barrier is maintained today through separate project areas in the file system and the product lifecycle management system, separate access groups, in some organizations separate physical space and separate personnel, and separate program reviews. In Formula 1 the surrounding structure is codified. Article 17 of the FIA Formula 1 Technical Regulations classifies every component of the car in terms of design, intellectual property, manufacture, and supply, into four categories: Listed Team Components, Standard Supply Components, Transferable Components, and Open Source Components, with the detailed classification set out in Appendix 5.10 The categories carry different constraints on who may perform the design work and who must hold the intellectual property. Similar structures, less formalized but no less real, govern OEM programs across the wider industry.
Where your barriers actually live today
Your information barriers are currently enforced by a combination of system permissions and human discipline. Human discipline is doing far more of the work than most organizations acknowledge.
A specialist engineer holds legitimate access to two competing programs because the organization is small and the expertise is scarce. That engineer knows not to carry a design concept from one client's program into the other, and does not, because they understand the obligation, they understand what it protects, and their professional standing in a field of a few thousand people depends on it. The permission system never prevented them from doing it. Their morals and judgment did.
An agent has no such judgment, and — this is the essential point — it does not need to be attacked for a barrier to fail. No injection is required. No credential is misused. No policy is violated. A barrier fails when a person with legitimate access to both programs asks a reasonable engineering question and the tool answers it correctly, drawing on everything it is authorized to see. Permission inheritance does not prevent this. Permission inheritance is what permits it, because the permissions being inherited belong to someone entitled to both sides who was relied upon not to combine them.
Read that finding the right way. It is not an argument against deploying agents. It is a precise statement of where your protection currently resides, and it is worth knowing independently of any technology decision. If a barrier only holds because a particular engineer exercises judgment, then it depends on that engineer's continued employment, attention, and care — and you cannot demonstrate it to a client audit team, because there is nothing to show.
This is the inversion worth carrying into the client conversation. Very few suppliers in this field can currently produce a document showing how program separation is enforced, by what mechanism, with what evidence. An organization that does the barrier work in order to deploy AI ends up holding exactly that document. The capability and the credential arrive together.
Condition two: much of the intellectual property in your systems is not yours
Practitioner position
A Tier-1 supplier's product lifecycle management system contains client-owned geometry, client-owned specifications, client release documentation, and design records generated under agreements that assign ownership to the client. The supplier is a custodian, not an owner, and the custodial obligation is defined in a supply agreement written before AI agents existed, which therefore says nothing specific about them.
When the data is your own, connecting an agent to it is a risk decision you are entitled to make. When it belongs to a client, connecting an agent to it may be a decision you are not contractually entitled to make alone. The controlling language is usually a clause restricting disclosure to third parties, or restricting processing to named facilities and named personnel. Whether an AI service provider constitutes a third party under that language is a question for counsel, and the answer varies by agreement.
Section Five addresses the more important half of this condition, which is that a great deal of what sits in your systems is yours, in quantity, and is currently doing nothing.
Condition three: the assessment regimes your clients use have not caught up
Established
There is currently no widely adopted third-party assessment scheme that asks whether an AI agent holds standing access to a client's confidential development data. The obligation exists — it falls under general access control, supplier management, and confidentiality requirements — but no assessor is presently prompted to ask the question directly.
The European automotive sector provides the clearest illustration because it has the most formalized scheme. Suppliers to German OEMs are commonly assessed against TISAX, operated by ENX on behalf of the German automotive association VDA, which includes a Prototype Protection module addressing pre-series and confidential development content.13 The current catalogue, VDA ISA 6.0, contains no control specific to artificial intelligence or autonomous agents. Neither does the successor catalogue published July 1, 2026.14
Most North American organizations have no direct exposure to TISAX and will not recognize the reference; Yet this point does not depend on it. The same gap appears in every regime a US supplier does operate under. ISO/IEC 27001 addresses information security management without reference to autonomous agents. Client-specific security requirements — which in the North American supply base do most of the work TISAX does in Europe — were largely written before this class of tool existed. Defense suppliers subject to CMMC face controls built around controlled unclassified information handled by people and systems, not by agents acting on a person's behalf.
The opening this creates
Passing your current security assessment, whichever applies to you, does not demonstrate that your AI integrations are governed. It demonstrates that nobody asked.
That gap will close, and the timing favors whoever moves first. When an AI-specific control appears in whichever scheme your clients use, an organization holding a documented position responds to a formality. An organization without one responds to a finding, under a deadline, in front of a client. The interval between now and then is the entire opportunity, and it is measured in quarters rather than years.
Two US-recognized frameworks provide workable structure in the interval. The NIST AI Risk Management Framework, with its Generative AI Profile published as NIST AI 600-1 in July 2024, is voluntary, well regarded in the US market, and addresses the risks discussed here.15 ISO/IEC 42001, published in 2023, provides a certifiable AI management system standard for organizations wanting third-party attestation.16 Either is defensible. Having neither, with nothing written down, is the position to avoid.
Condition four: where export control applies, the exposure is legal rather than commercial
Emerging
For organizations whose work touches defense, aerospace, or dual-use technology, controlled technical data is subject to the International Traffic in Arms Regulations or the Export Administration Regulations. Under these regimes, making controlled technical data accessible to a foreign person constitutes an export, whether or not the data crosses a physical border.
How agent architectures map onto these obligations is an area where practice is still forming and published regulatory guidance specific to AI agents is limited. The governing principle is unchanged — the obligation attaches to access by a foreign person, and to where data is stored and processed — but its application to a multi-layered agent architecture with distributed inference is not yet settled. Treat any agent integration touching controlled data as requiring specific export control counsel review rather than general procurement. This is not the area in which to rely on a vendor's general assurance.
Section Five
Learning across barriers: the compounding asset that makes a specialist
Practitioner position — novel framing
Start from what is true about this industry rather than from what is risky about the technology.
A client does not come to a specialist supplier because that supplier has never made anything like this before. A client comes precisely because the supplier has made components in this family, for this duty cycle, in this material, for years, across many programs and many customers — and therefore knows what will run, what will crack, what the real process window is, and what the drawing will cost to hold. Accumulated cross-program learning is not an unfortunate side effect of serving competitors. It is the product. It is what a client is buying and it is what justifies the price.
Any framework that concludes a supplier should learn nothing across its programs has produced the wrong answer. It would make every client worse off, including the one it purported to protect. The correct question is not whether to learn across programs. It is which layer of knowledge may be pooled, and which must stay partitioned — and that question has a clean, defensible, and largely conventional answer.
The two layers, and who owns each
Intellectual property in a supply relationship is not one undifferentiated mass. It stratifies, and the stratification is already recognized in the contracts you have signed.
Commercial practice distinguishes background intellectual property — what each party brought to the relationship — from foreground intellectual property created during the engagement. Absent contract language to the contrary, background IP stays with its owner, and process improvements and general manufacturing know-how developed by the manufacturer remain the manufacturer's.17 A manufacturer's process assets are recognized in valuation practice as a distinct class: proprietary manufacturing methods, heat treatment sequences, machining strategies, tooling and fixture designs, inspection methods, and quality control systems, developed over years and constituting the firm's accumulated expertise.18
Applied to a specialist engineering supplier, the two layers separate as follows.
The client layer — the what
Design geometry and models. Functional specifications and performance targets. Tolerance schemes as applied to a specific part. Application context: where the component sits, what it does, what it is being asked to survive. Test results tied to a specific design. Program timing, and the client's own development intent.
This layer is partitioned. It does not cross a barrier, in any form, by any mechanism, ever. It is the client's competitive advantage and they paid for it. Normally it is protected by MNDA, regardless the position is clear.
The supplier layer — the how
Machining strategies and cutting parameters by material and feature class. Fixturing and workholding approaches. Heat treat and surface treatment recipes and their outcomes. Process capability by feature type. Tool life against material lot, machine, and operator. Setup and changeover times. Scrap and rework causes, and their frequencies. First-pass yield and where it is actually lost. Inspection methods and gauge repeatability. Supplier lead times, quality history, and real cost structure. Machine utilization and maintenance history.
This layer is yours. It was developed at your expense, it lives in your systems, and pooling it across every program you run is not a barrier violation. It is the entire basis of your specialty.
The consequence is direct and it is the central practical finding of this paper. An agent scoped to the supplier layer, drawing across all programs, is not a risk to be contained. It is your core value proposition, industrialized. It is also, conveniently, where the largest and most neglected dataset in your organization already sits.
Run data: the asset you already own and are not using
Consider what a mid-sized specialist shop accumulates in five years and never analyzes: every setup sheet, every tool change, every dimensional inspection record, every non-conformance and its disposition, every machine alarm, every scrap ticket with a cause code, every quote and every actual against it.
Almost none of this is client-owned. Nearly all of it is untouched, because extracting anything from it has always required an engineer with time, and no specialist shop has an engineer with time. This is exactly the constraint the technology addresses, and it addresses it on the side of the boundary where you owe nobody an explanation.
The questions that become answerable are the ones that determine whether a program makes money:
Where does yield actually go?
Not the aggregate scrap rate, which everyone already knows. The specific combination — feature, material lot, machine, tool vendor, shift, setup sequence — under which scrap concentrates. That correlation exists in your records today and no one has the hours to find it.
What is our real process capability, by feature class?
Capability studies are typically performed per part, per program, on demand. Aggregated across every part your shop has produced with that feature type in that material, capability becomes a quoting instrument: you learn which tolerances you actually hold, which you hold with difficulty, and which you have been absorbing losses on for years.
Which quotes were wrong, and in which direction?
Quoted hours against actual hours, resolved by operation and by feature rather than by job, across every program. This is the difference between quoting from experience and quoting from evidence, and it goes directly to margin.
What does this supplier's quality history actually say?
Incoming inspection results, lead time performance, and cost by supplier and material class, aggregated across programs. Your supply base is your own commercial relationship and its performance data is yours.
This is the pilot to run first, and not as a cautious fallback while the difficult questions are resolved. It is the highest-value target available and it carries no barrier exposure. An organization that spends its first year here builds real capability, produces the audit and configuration evidence it will need later, improves its own margin, and never once has to ask a client for permission. The companion paper The Core Competency You Already Own (September 2026) develops this application in full: what is in the historical record, the four tiers of value it yields, and how a measured competency map changes what an organization prices, pursues, and declines.
Where the layers blur, and the test that resolves it
Practitioner position
The stratification is clean as a principle and messy at the boundary. Intellectual honesty requires stating where.
A process parameter can be design-revealing. A note that a particular operation runs at reduced depth of cut because the wall is thin at that station encodes geometry. Process capability reported against a specific feature reveals the tolerance the client specified. A fixturing strategy can imply the shape of the part. Aggregate data drawn from a population of one program is not aggregate data — it is that program's data with a different label on it.
The working test is abstraction, and it is implementable:
"Thin-wall features below a given ratio in this alloy require reduced depth of cut and this tool geometry to hold the tolerance" passes. It is a machining rule, applicable to any part with that feature and physics, and it is the kind of knowledge that makes your shop worth hiring. "The intake side of Client A's component has a thin wall at this station" fails. It is simply client specific geometry without the physics why.
Two supplementary rules make the test practical. First, require a minimum population: a process rule derived from a single program without using first order engineering calculations is not a rule, and should be excluded from any pooled data set until it appears across several. Second, check direction of flow. General knowledge applied to a specific client's problem is exactly right. One client's specific finding applied to another client's problem is not, however it is phrased.
The residuals question is worth raising here, because it bears on where the line sits when it is genuinely ambiguous. Many confidentiality agreements contain a residuals clause permitting use of information retained in the unaided memory of individuals who had authorized access, while excluding use of tangible materials.12 An agent's retention is aided by definition: stored, indexed, mechanically retrievable. On a plain reading, machine retention appears to fall outside the residuals exception entirely. If that reading is correct, an organization relying on residuals language to justify cross-program AI use is relying on protection it does not have. This has not to my knowledge been tested in litigation, and the residuals commentary currently in circulation does not discuss AI at all.12 It is offered as a question for counsel, not a legal conclusion — and it is far cheaper to ask before an integration than after one. It is also an argument for building on the supplier layer, where the question does not arise.
What must be partitioned: three vectors, in increasing order of permanence
Once the layers are identified, enforcing them is an architecture problem with three distinct parts. They require different controls and differ sharply in reversibility.
Vector one — within a session
The agent reads from Program A and Program B while answering a single question and synthesizes across both. The most common, the least permanent, the most straightforward to control: scope reach to a single program, or enforce a policy forbidding cross-program reads within one session. This is layer-two deterministic policy from Section Three, applied to a checkable rule.
Vector two- persistent indexes and memory
Substantially more serious and much less visible. Deployments improve their usefulness by building persistent artifacts over your data: retrieval indexes, embedding stores, agent memory carried between sessions. A retrieval index built across your entire engineering repository is, by construction, a single object spanning every information barrier in your organization. The barriers exist in the source systems; the index does not reproduce them unless deliberately built to. This failure is recognized in the security literature as its own category.11
The control is architectural and must be specified before the system is built: partition indexes on the client layer, pool them on the supplier layer. One index per program for design content; one shared index across all programs for process, quality, and production data. This is the single most consequential design decision in the entire deployment, and retrofitting it after a unified index exists means rebuilding it.
Vector three — training and fine-tuning
The most permanent and least reversible. If client-owned data is used to train or fine-tune a model, the derived understanding is embedded in the model's parameters. It cannot be located, attributed, audited, or removed, and it is present in every response thereafter, for every user, on every program.
The control is contractual and absolute, and it is the one item in this paper that should be non-negotiable: obtain written confirmation that your data is not used for model training, and confirm which contract tier that commitment attaches to. The distinction between consumer and enterprise terms is frequently exactly this, and organizations regularly deploy under the wrong tier without noticing.
Asking for more: the consent path
Practitioner position
The stratification above defines what a supplier may pool unilaterally. It is not the outer limit of what is available, because clients can agree to more — and in the right framing, frequently will.
There is real value in cross-program analysis that sits above the supplier layer: a materials failure database spanning multiple programs, fatigue performance of a coating across different duty cycles, a supplier quality picture built from many clients' incoming inspection results. None of this can be pooled unilaterally. All of it can be pooled with consent, and consent is obtainable when the benefit returns to the participant.
The proposition to a client is straightforward and does not require a general release: their data participates in a defined, aggregated analysis on a named question, with a stated abstraction level, and they receive the result. A client who contributes fatigue data on a coating gets back a picture built from a population none of them could assemble alone. The supplier organizes it. Everyone is better off, and nobody's geometry has to be shared to achieve it.
This requires a supplier that can describe its controls precisely, which returns to Section Four. The barrier work is the prerequisite for the consent conversation. A client will not agree to aggregated participation with a supplier that cannot explain how its partitions are enforced, and will consider it with one that can.
The position, stated plainly
A supplier's obligation to its clients is not to refuse to learn. A supplier that learns nothing across its programs is worth less to every client it serves, and would not survive in this industry.
The obligation is that what the supplier learns and redeploys is what the supplier owns- the process, the capability, the accumulated understanding of how to make things of this kind- and that each client's design advantage stays with that client. Every architectural decision in this section, from index partitioning to training terms to the abstraction test, is a mechanism for enforcing that single distinction.
Stated that way, it is a rule an engineering organization can implement, audit against, and explain to a client without hedging. It is also a considerably better outcome for every client than the alternative on offer, which is a supplier that either learns nothing or learns without a line.
Section Six
Six questions that clear an integration for deployment
Practitioner framework
These six questions are a practitioner framework rather than a published standard. They are a structure for a decision most organizations are currently making without one, and they are written to produce a yes where a yes is warranted. They can be worked through in a half day by an engineering lead, a quality or information security lead, and whoever holds commercial responsibility for the client agreements involved. That third participant is not optional.
Question One
Which layer does this connection touch: The client layer or the supplier layer?
Answer this first, because it determines how much of the rest applies. An integration confined to your own process, production, and quality data clears most of what follows immediately and should be moved on quickly. An integration touching client design content requires every remaining question answered.
Classify the specific systems and record types, not the platform. Most systems hold both layers (a product lifecycle management system contains client geometry and your own manufacturing process records) so the classification is by content, and the scoping must follow it.
Question Two
Does this connection preserve the information barriers you have promised your clients?
Identify every barrier your organization maintains between client programs. For each, determine honestly whether it is enforced by system permissions, by physical or organizational separation, or by the professional discipline of the individuals involved.
Barriers enforced by system permissions survive an agent integration, because the agent inherits them. Barriers enforced by professional discipline do not, because the agent has no professional discipline and the person directing it holds legitimate access to both sides. Expect to find more barriers in the second category than you assumed.
Where a barrier is not enforced in the permission system, make it so before connecting an agent, or scope the agent to a single program. This work has value whether or not the integration proceeds: it converts an assurance you cannot demonstrate into a control you can.
Question Three
What persists between sessions (indexes, memory, and training) and is it partitioned on the client layer and pooled on the supplier layer?
Question Two addresses what the agent can reach now. This addresses what it retains, where the irreversible exposure lives and where the compounding value lives.
Put three questions to the vendor and require specific answers. First: is a retrieval index or embedding store built over our data, is it one index or many, and can retrieval be constrained to a program boundary? Second: does the agent retain memory between sessions, where is it stored, and can it be partitioned or disabled? Third: is our data used to train or fine-tune any model, under which contract tier, and will you confirm that in writing?
The third answer should be an unqualified no, in writing. The first two determine whether the architecture can support the stratification at all, and must be settled before the system is built.
Question Four
What can this agent change, transmit, or publish, as distinct from what it can read?
The read bit and the write bit, separated. Require the vendor to enumerate write operations, not summarize them: create record, update field, transition status, send message, attach document, generate outbound communication. If the vendor cannot produce that list, the evaluation is not ready to proceed.
For each, apply one test: if this action were performed incorrectly, at scale, without anyone noticing for a week, what is the consequence? An incorrectly updated internal task is low. An incorrectly transmitted document, an incorrectly released engineering change, or an outbound communication to a client is high.
High-consequence actions require explicit human confirmation at execution, enforced outside the model rather than by instructing it. Note that a read-only configuration clears this question entirely, which is why the first pilot should usually be one.
Question Five
What untrusted external content can reach this agent's context, and what stops it directing the agent's actions?
Map the paths by which text originating outside your organization arrives in a system the agent can read: incoming email, supplier quotations, client portal submissions, requirement documents received as attachments, field reports, any document system ingesting external files.
Where an agent has both a path to untrusted content and the ability to perform a high-consequence write, you have reproduced the configuration every documented incident exploited. Ask the vendor how trusted instruction is distinguished from untrusted retrieved content, and what mechanism outside the model prevents the latter directing the former. A vendor whose answer is that the model is trained to recognize malicious instructions has not answered the question.
Where no such mechanism exists, break the pairing architecturally: one configuration reads untrusted content and cannot act, another acts and reads only internal sources.
Question Six
Six months from now, can you demonstrate to a client exactly what this agent accessed and what it did?
Ask the vendor for a sample audit record — not a description of the logging capability, an actual example. Evaluate it against a specific scenario: a client asks you to demonstrate that their program data was not accessed in connection with a competitor's program during a defined period.
The record must identify the user, the action, the specific records reached, the timestamp, and the initiating instruction. It must be retained consistent with your client agreements and quality management system, and be exportable for third-party review.
Note the limit. An audit record shows that records were read. It does not show what was derived from reading them. That is why Questions One through Three matter more than this one, and why prevention at the architecture level cannot be replaced by detection afterward. Note also the opportunity: an exportable record of enforced separation is a document very few of your competitors can produce.
Section Seven
Where to start on Monday
The gap between recognizing this and holding a governed, deployable position is smaller than most organizations assume. Five actions can be initiated this week, without a vendor in the room and without a budget line.
Inventory your systems of record by data ownership, not by system name.
One table. One row per system: product lifecycle management, enterprise resource planning, manufacturing execution, quality management, document control, customer relationship management, email, engineering file storage. Columns: what fraction of the content is client layer, what fraction is supplier layer, and which agreement governs the client-owned portion.
Most organizations have never assembled this view. Assembling it changes the conversation immediately, usually in both directions: the concentration of client-owned intellectual property is rarely where people expected, and the volume of wholly owned process data is almost always larger than anyone had considered using.
Write down which of your barriers are enforced by permissions and which by discipline.
A one-page document and the highest-value hour available to you this week. List every barrier between competing client programs. For each, mark whether it would survive if a person with legitimate access to both sides had a tool capable of synthesizing across everything they can see.
The barriers failing that test are your exposure today, before any AI decision is made, because that same list tells you how much of your clients' confidence currently rests on individual judgment rather than system design. Closing those gaps is worth doing on its own merits, and it is the prerequisite for everything else.
Find out where AI tools are already connected.
This step routinely produces surprises. Integrations arrive as features inside software you already license, enabled by default in a version upgrade, or switched on by an engineer who found a productivity gain and had the rights to enable it. The engineer was not acting improperly; the tool was presented as a feature of approved software.
Ask each system owner directly: has any AI assistant, copilot, or agent feature been enabled here, by whom, with what scope, and has any indexing or memory feature been switched on. Establish the current state before designing the future one.
Start the first deployment on your own production and quality data.
Not as a cautious holding action, rather as the highest-value target you have. Scrap and rework by cause, process capability by feature class, tool life, quoted against actual hours, supplier quality and lead time performance. This is the supplier layer, it is entirely yours, it is almost certainly unexploited, and it goes straight to margin.
Run it read-only to begin with. You develop the organizational capability, generate the audit and configuration evidence you will need for the harder conversations, improve your own numbers, and never once have to ask a client for permission.
Take the position to your largest client before they bring it to you.
A supplier arriving with a written AI governance position, a system inventory, a barrier map, and a clear articulation of which layer it pools and which it partitions is establishing a competitive position, not managing a liability. Very few of your competitors will have done this work in the present time.
The same conversation opens the consent path in Section Five. A client who understands your controls is a client who can be asked about aggregated analysis, and that is where the next tier of value sits.
The controls that protect intellectual property in an engineering organization have always been a combination of systems and judgment. What changes with an autonomous agent is that judgment no longer travels with the access. Building systems that carry the obligation on their own is work, and it produces something the judgment never could, which is proof.
About this paper
About this paper
This paper was written for owners, general managers, and engineering leaders in motorsport, high-performance automotive, and Tier-1 supply organizations who are being asked to approve AI integrations into systems that hold intellectual property belonging to their clients.
It is one of three related papers. Augmentation or Replacement (May 2026) addresses which AI tools to adopt and what their adoption does to engineering capability. This paper addresses what those tools may touch, what they may retain, and how the boundary is drawn so the capability can actually be used. The Core Competency You Already Own (September 2026) develops the application on the supplier side of that boundary: establishing measured core competency from the production history an organization already holds.
The argument is grounded in 25 years of engineering leadership across competitive series including CART, IndyCar, and NASCAR, and in Tier-1 supply programs serving OEM customers and Formula 1 and MotoGP teams, together with direct experience deploying machine learning and AI systems in operational engineering programs since 2017.
A note on evidence in this paper
Sections carry a label indicating the strength of the evidence behind them. Established means the claim is documented in published standards, peer-reviewed work, or primary vendor and regulatory sources, cited in the notes. Emerging means the evidence exists but the field has not settled. Practitioner position means the claim reflects operational judgment developed across specific programs rather than published research, and should be evaluated as such.
Specifically: the client layer and supplier layer stratification in Section Five rests on the established background and foreground intellectual property framework, but its application to AI scoping is my own and the allocation in any specific relationship is whatever that contract says it is — read yours. The abstraction test and the six-question framework are practitioner frameworks, not published standards. The reading of residuals clauses in Section Five is a novel argument, identified as such, offered as a question for counsel rather than a legal conclusion. The Salesforce and Anthropic integration described in Section One is, as of this writing, in limited pilot with an open beta expected in September 2026;1 nothing here depends on that product performing as described.
Nothing in this paper constitutes legal advice. The contractual, residuals, and export control questions raised in Sections Four, Five, and Six require review by qualified counsel familiar with your specific agreements and your specific regulatory position.
Notes
Salesforce and Anthropic (August 26, 2026). Salesforce and Anthropic Announce Claudeforce. salesforce.com. The permission inheritance description and the pilot and beta timing are corroborated by contemporaneous reporting: VentureBeat (August 26, 2026), venturebeat.com.
Ray, S. (May 2, 2023). Samsung bans ChatGPT among employees after sensitive code leak. Forbes. forbes.com. See also the AI Incident Database record, Incident 768: incidentdatabase.ai.
OWASP Top 10 for Large Language Model Applications, 2026 edition, published August 2026. Excessive Agency moved from LLM06 in the 2025 edition to LLM03 in 2026, the largest single change in the list. Note: secondary sources give slightly different publication dates in early and mid August 2026; the ranking change itself is consistently reported. See HackerDNA analysis, hackerdna.com, and Check Point Research commentary, checkpoint.com.
Check Point (August 2026). Reading the signals in the OWASP LLM Top 10 2026. checkpoint.com. See also ReversingLabs commentary on the same revision regarding containment of agent capability as the primary control: reversinglabs.com.
Ritchie, D.M. & Thompson, K. (1974). The UNIX time-sharing system. Communications of the ACM, 17(7), 365–375. The nine-bit read/write/execute model across owner, group, and other classes was introduced in the fourth edition of UNIX in 1973, replacing the earlier five-bit scheme, and is the model subsequently specified by POSIX and implemented in current UNIX and UNIX-like systems. Summary of the model and its version history: en.wikipedia.org/wiki/File-system_permissions.
Saltzer, J.H. & Schroeder, M.D. (1975). The protection of information in computer systems. Proceedings of the IEEE, 63(9), 1278–1308. Full text: cs.virginia.edu. The principle of least privilege is stated among the eight design principles. For a modern reassessment, see Smith, R.E. (2012), A contemporary look at Saltzer and Schroeder's 1975 design principles, IEEE Security & Privacy, 10(6), 20–25.
Invariant Labs (May 26, 2025). GitHub MCP Exploited: Accessing private repositories via MCP. invariantlabs.ai. The researchers state the issue is architectural rather than a defect in the integration code, and that server-side remediation alone is insufficient. Independently reported: devclass (May 27, 2025), devclass.com.
Checkmarx. MCP Security: Risks, Real Incidents and Controls (2026). checkmarx.com. Documents incidents including the compromised postmark-mcp npm package (September 2025), which silently added a blind carbon copy to outbound email, and a multi-tenant isolation defect in a project management platform's AI feature (April 2025).
Debenedetti, E., Shumailov, I., Fan, T., Hayes, J., Carlini, N., Fabian, D., Kern, C., Shi, C., Terzis, A. & Tramèr, F. (2025). Defeating Prompt Injections by Design. arXiv:2503.18813 (submitted March 24, 2025; revised June 24, 2025). arxiv.org/abs/2503.18813. Reference implementation: github.com/google-research/camel-prompt-injection. The 77 percent versus 84 percent task completion figures are the authors' reported results on the AgentDojo benchmark. Note: preprint with an associated reference implementation; readers should check current publication status.
FIA Formula 1 Technical Regulations, Article 17 (Components' Classification), Articles 17.1 to 17.7, and Appendix 5 (Components' Classification and Perimeter). Note that Article 17 sits in the Technical Regulations; the Sporting Regulations reference it at Article 6.3 in defining a constructor. See the 2025 Technical Regulations, fia.com. Consult the current issue directly, as article and appendix numbering is revised between seasons. Plain-language summary: planetf1.com.
OWASP Top 10 for Large Language Model Applications, entry LLM09, Vector and Embedding Weaknesses, addressing access control failures in retrieval-augmented generation systems. See the OWASP GenAI Security Project, genai.owasp.org.
Morgan Lewis (August 2025). Residuals clauses vs. feedback licenses: getting the balance right in IP agreements. morganlewis.com. Describes the standard construction permitting use of information retained in unaided memory while excluding tangible materials, and notes the difficulty of separating retained know-how from confidential material. This source does not address artificial intelligence. The application of residuals language to machine retention advanced in Section Five is the author's argument, not the source's, and has not to the author's knowledge been tested.
TISAX is operated by ENX Association on behalf of the VDA. Module structure comprises Information Security, Prototype Protection, and Data Protection. See VDA information security overview, vda.de, and TÜV SÜD assessment overview, tuvsud.com. TISAX applies primarily to suppliers to European, and particularly German, vehicle manufacturers; most North American suppliers meet equivalent obligations through client-specific security requirements instead.
VDA ISA 6.0 was published October 16, 2023 and became mandatory for new assessments from April 1, 2024; current revision 6.0.3. The successor catalogue, designated ISA 2027, was published July 1, 2026; the binding transition date is to be set by ENX. Principal revisions address crisis management, teleworking, and supplier verification. Neither catalogue introduces an artificial intelligence control or module. See ITIS-Secure catalogue analysis, itis-secure.com, and Valiido ISA 2027 change analysis, valiido.com. Verify current catalogue status with your assessment provider before relying on this summary.
National Institute of Standards and Technology. AI Risk Management Framework (AI RMF 1.0), January 2023, and Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, July 2024. nist.gov; full Generative AI Profile text at nvlpubs.nist.gov. An agentic profile extending the framework to autonomous agents is under development through the Cloud Security Alliance and should be reviewed as it matures.
ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system. iso.org. Adopted as EN ISO/IEC 42001:2026 in the European standards system. Certification is available through accredited bodies including BSI and TÜV SÜD.
On the background and foreground intellectual property framework in contract manufacturing, and the default position that manufacturers retain process improvements and general manufacturing know-how absent an express assignment or improvements-ownership clause: gtsetu.com. See also the Association of Corporate Counsel resource on ownership language in IP contracts, acc.com. Important qualification: this allocation is contractual, not automatic. Many OEM supply agreements expressly assign foreground IP and process improvements to the customer. The stratification proposed in Section Five is a principle for organizing the question; the line in any specific relationship is wherever that agreement puts it.
On manufacturing process intellectual property as a distinct class of intangible asset — proprietary manufacturing methods, heat treatment sequences, machining strategies, tooling and fixture designs, inspection methods, and quality control systems — see opag.io. Trade secret protection for such assets in the United States arises under the Defend Trade Secrets Act of 2016 and applicable state law, and depends on the holder taking reasonable measures to maintain secrecy — a requirement that itself bears on how these systems are configured.