Require all agent/LLM access to systems of record to go through inspectable static code, never direct LLM access
Situation
Peter opened the 7/24 Jira Automation call with Karl Lowenbjer by setting a condition before taking Karls agenda. The rule: no LLM gets direct access to a system of record. In every instance the LLM writes code that accesses the system, and that code is inspectable by a human or by another LLM. He stated he wants this true for everything Karls team builds, and that as long as it is true he is comfortable. He explicitly accepted that the filters themselves may be wrong - we might make a mistake in terms of what we pull in and out and that is fine, I do not mind mistakes - but the mechanism is non-negotiable. Karl confirmed Atlas already works this way. Peter then closed the topic without further discussion.
Reasoning
The failure mode Peter is designing against is non-determinism, not leakage. His operative phrase was never subject to the vagaries of an LLM. A wrong filter in static code is a bug you find and fix once; a model that sometimes pulls the wrong field is an unbounded liability that cannot be audited. That is why he volunteered that mistakes are acceptable - he is trading correctness-on-first-try for auditability and consistency. This is the coherent complement to his 6/18 rejection of centralized AI governance on internal AI tools: where a human is in the loop, optimize adoption and accept eventual leakage; where an agent touches a system of record unattended, constrain the integration mechanism absolutely. He is also generalizing from validated personal practice - he runs agents against Slack, Jira, email, and calendar himself under exactly this constraint - so he is stating a standard he has proven rather than imposing an untested policy.
Additional Context
Raised because of the BigQuery/Fivetran support-metadata exposure that surfaced the previous day, which Peter had already judged substantively a non-issue. He used the live incident as the occasion to set the architectural rule before Karls team built the next integration loosely, rather than to litigate the incident itself. Karl does not report to Peter - Bjorn had asked Karl to move work into Jira and to mirror how engineering operates.
Observed Evidence
Extended direct quote opening the call, unprompted and ahead of the stated agenda. Followed by the explicit acceptance of filter mistakes and the explicit scoping to everything that you guys are building.
Matching Patterns
Confidence Breakdown
Reasoning Depth Analysis
People Involved
Source
reflection
AI Confidence
80%
Related Context
fathom
There is no world that I live in right now, even though I have got a bunch of agents that run against Slack, Jira, email, calendars, etc. There is no world where I have an LLM that has direct access to those systems. What I have in every instance is the LLM has written code that accesses those systems... So the access is always through a chunk of code that can be inspected, inspected by another LLM, etc. So it means that the data ingress and egress from those systems is always consistent, never subject to the vagaries of an LLM. That is, I want to ensure that that is true for everything that you guys are building.
Outcome
Re-delivered at the Jul 31 AI Committee with no dissent; Michelle publishing it with Peters name attached; Ryan Smith filed CUSP-3473 on Aug 5 turning it into a Customer Engineering department standard with Mission Control and butler-go as reference implementations, reproducing the three pillars back verbatim.
Rating: 5/5
Decision ID: 3bd8a65f-c3f0-4bdd-9253-0ecbb7abedb4