Trust
How we control the AI agents we run for your work
Putting AI agents into real work is a question of responsibility. A well-built agent can still cause an accident if it holds the wrong permissions. So the first thing to check about us is what we never let AI do, and how we enforce that. This page answers that question.
MSSJ · as of August 2026
Why this matters now
These failures have already happened
Gartner has forecast that by 2027, 40% of companies will roll back AI agents they had adopted. It named failed permission design as the cause. Several organizations have already paid a price at exactly this point.
Air Canada
A chatbot gave refund information that differed from the real refund policy. A customer trusted it and bought a ticket. A Canadian tribunal said the chatbot is part of the company and held the airline liable. It found that the company could not treat the chatbot as a separate legal entity.
2024 · Canadian civil tribunal decision
Samsung Electronics
In 2023, employees pasted chip equipment source code and meeting recordings into ChatGPT, three times within 20 days. The company soon banned outside generative AI on all company devices and turned to building its own AI platform.
2023 · Samsung Electronics internal measure
Replit AI agent
A developer clearly ordered a "code freeze". A coding agent still deleted an entire production database that held records on about 1,200 executives. The permission to decide what to do and the permission to carry it out were not separated.
2025 · Publicly reported development case
Mata v. Avianca
A law firm filed a court brief that cited six court cases made up by AI. The cases did not exist, and nobody checked them. The judge imposed a fine and ordered the firm to send correction letters to all the courts involved.
2023 · U.S. federal court decision
The four cases fail at sending, data, permissions and checking. These are the same points that the five controls below are built to cover.
People make the decisions, and agents carry out the work
We split work into two layers. This boundary is fixed as an operating rule. The five controls below support it.
People do this
Decide, check, approve: what to do, whether the result is right, and whether it can go out.
Agents do this
Collect, analyze, draft, and repeat routine steps.
Five controls
Tasks only people do: the non-delegable list
We never give the tasks below to an agent, in any situation. Agents only prepare, draft and cross-check. Then they stop.
Money
Payments · money transfers · bank account changes · tax filing
Legal commitments
Signing contracts · signatures · official submissions
People
Hiring · dismissal · HR decisions
Information
Handling personal data · sending or publishing anything to customers or outside parties
We want to stress one point: only people send anything outside the company. There is no path for documents, messages or numbers made by an agent to go straight to a customer or a third party.
Permission levels and approval
Every agent is given a level. Any action above that level needs approval from a person.
| Level | What it may do | Approval |
|---|---|---|
| 1 | Viewing · analysis · monitoring | Not needed |
| 2 | Writing internal drafts | Not needed (internal use only) |
| 3 | Internal actions within an approved scope | Within the scope approved in advance |
| 4 | Changes to live systems · sending outside · publishing | Approval by the responsible manager |
| 5 | Contracts · payments · legal matters · HR | Approval by the CEO |
We set up an agent only after these points are written down: the team it belongs to, its task, the data it can read, what it may run, the points where a person approves, and where its results are recorded. We do not keep any agent whose job we cannot state.
Work records: what was done is kept
We record which request came in, which information was used, which tools were called and what was produced. When the work ends, the decisions, evidence, open items and next steps are fixed in a document. The list of outputs is locked with file hashes (a digital fingerprint of each file). Later, anyone can trace what a past decision was based on.
Output checks: numbers and verdicts do not go out unchecked
Numbers, assessments, forecasts and “done” verdicts made by an agent are only reference values on their own. A check is required at the moment one of them goes into a customer report, becomes the basis for a decision or is saved as a baseline. The strength of the check is set by how much is at stake. Work that is hard to undo, numbers that go outside and values that conflict with earlier measurements get the highest level, with a repeat check and an opposing review.
The key point is that a program enforces this decision, so it does not depend on a person's discretion. The decision logic is written in code, and automatic tests check it on a regular basis.
Latest check results (re-run on August 11, 2026)
All judged correctly
Every representative test case got the right decision.
No rule broken
Each safety rule was tested against every combination of input conditions it can meet.
The most important rule is this: a value that is unverified, or that conflicts with earlier measurements, can never be used as the basis for an action. The label “unverified” means “do not use”. It does not excuse anyone.
Separation: customer data is not mixed
For each customer and each project, we keep the work scope, the materials that can be accessed and the login credentials separate. A basic operating condition is that one customer's materials, history and credentials are not exposed to work for another customer or another project. In training, when many learners practice at the same time, each participant works in a separate environment.
How it is enforced
How the decision is enforced in practice
Here is what “enforced by code” means in more detail. There is one principle: the judgment about what to do and the enforcement that checks whether the fixed rules were kept are never placed in the same spot.
Judgment is flexible
What to do and how many resources to use differ in each case. An agent or a person makes this judgment to fit the context.
Enforcement is fixed
One part checks whether that judgment broke a fixed rule, such as the non-delegable list or a permission level. We lock this part in code that always reaches the same result, without a person reviewing it each time.
Every listed combination of input conditions is tested
When we add a rule, we list every combination of input conditions that the rule could apply to. Then we confirm that the rule works in all of them, with no exceptions. The check results above come from this test.
We keep the part that should be flexible (judgment) apart from the part that must be fixed (enforcement). This is what we mean by “enforced by code”.
Limits
What we do not do yet
We list our current limits before our strengths, exactly as they stand today.
- 01
We do not yet track, as a number, how often automatic assessment agrees with expert judgment.
We check conclusions by crossing several independent review paths. But we do not yet run a measure of what percent of automatic assessments match expert judgment.
- 02
We have no formal test set for malicious input.
Some attacks hide instructions in outside documents or data to make an agent misbehave. We have structural blocks against this (separated permissions, and only people send anything outside). We have not yet made regular simulated attack tests a routine.
- 03
No automatic re-check stops a release when settings change.
When the AI model or the reference materials change, a person currently decides on the re-check and carries it out.
- 04
Some controls need to be checked together at the start of a project.
Some of the controls above run all the time in our own company operations. Others are set up for each project when it starts. We show which is which with evidence.
We manage these four items as targets for improvement. In adoption talks, we share their current status as it is.
Evidence you can ask us for
While you review adoption, you can request the items below. We provide them within the scope of your request.
- A specification of each agent used in the project: its task, the data it can access, its permission level and the points where a person approves
- A written confirmation of how the non-delegable items apply to this project
- The standards for each output check level, and the level that applies to what we deliver to you
- The data handling scope: which materials are read, where they are stored and when they are deleted
- How work records are kept, and how to look them up
- The steps for notice, shutdown and recovery if an incident happens
- How the limits listed above affect this project, and how we will make up for them
What we agree on before we start
How far agents go and where people take over is decided separately for each type of work. Before we start, we fix the three points below with you.
- 01
At which points in this project must a person make the decision?
- 02
How far can the agents access your materials?
- 03
Who checks the results before they go out to you?
We do not start work until these three points are decided.
Find out how much of your work agents can take on
Tell us about your work and your data setup. We will first send you a plan that splits the points people handle from the points agents handle.
Contact us about adoption