A rule. A person. A receipt. Every time.
The frightening part of letting software touch your infrastructure was never that it might propose something bad. It is that nobody would stop it. So nothing here acts on its own: every change is measured against your rules and authorized by a named person, and what happened afterwards is written down while it happens.
Four things we will not trade away.
Everything below is an elaboration of these. If you only read one section, read this one.
A better-worded request is not a better argument.
Your limits are evaluated against what a change would actually do — not against the conversation that produced it. The evaluation does not read the request's tone, and it does not weigh how reasonable the explanation sounded.
- Regions you have not permitted are refused before anyone is asked to review
- Changes above your cost ceiling are refused automatically
- Deletes and replacements always require a person, regardless of any other outcome
- Refusal is deterministic — rephrasing the same request does not change the answer
Software proposes. A person authorizes.
The concern worth taking seriously is not that you would approve something. It is that you would approve one thing and something adjacent would run. That cannot happen here: what you reviewed is what executes.
- Approval attaches to the exact change you reviewed, not to a summary of it
- Alter the change and the earlier approval does not carry forward
- No agent or automation can approve its own work
- Automated triggers — including corrections for drift — propose only, and wait
Nothing holds a permanent key to your cloud.
If a credential to your infrastructure ever leaked, the damage should end where the job ended — not follow you around for months afterwards. So there is no shared, long-lived account sitting behind this waiting to be misused.
Access is granted only after a change is approved, only as wide as that change requires, and only for as long as the work takes. When the job ends the access ends with it, whether the job succeeded or not.
The moment access is granted is itself recorded, and tied to the person who approved the work it was granted for.
What this rules out
An AI agent that could reach your infrastructure whenever it wanted to.
A stored key that keeps working long after the reason for it has passed.
A compromised automation quietly acting outside the work it was authorized for.
A change nobody can trace back to a person.
If something goes wrong, you should not have to take our word for what happened.
The record exists to answer questions asked months later by people who were not in the room. These are the questions it is built to answer.
| The question | What the record gives you |
|---|---|
| Who asked for this? | The original request, the person who made it, and when. |
| Who allowed it? | The person who authorized it, what they authorized, and when they did. |
| Why was this refused? | Which of your rules applied and what it decided — refusals are kept as carefully as approvals. |
| What actually changed? | What was applied, and whether the result matched what was asked for. |
| Who could reach our account, and when? | Every grant of access, the work it was granted for, and the approval behind it. |
| Can we have all of it? | Yes — the record is exportable. It is yours, not a view we render for you. |
These records are written at the moment each thing happens and are not editable afterwards — including by us. That property is the point of keeping them.
Deleting a person actually deletes them.
“Deleted” usually means a row was hidden, and then quietly restored with the next backup. Personal data here is encrypted under a key belonging to that individual alone, and erasing them destroys the key — so the data cannot be read again, including from a restored backup.
- Erasure is irreversible by design; no support escalation recovers it
- Everyone else is unaffected — the key was theirs, not the organization's
- Export and erasure are self-service, for the individual or an administrator acting for them
- The record of what happened survives, because it never held personal data to begin with
The parts people find surprising.
Better to read them here than to discover them during an audit.
- A request covers one organization, because that organization controls what it holds. Someone in three organizations makes three requests
- Erasing someone from one organization does not remove them from another that still has them as a member
- One customer can never erase, read or affect what another customer holds
- Erasure is permanent. A key that could be recovered was never really destroyed
A rule that bends to a better-worded request was never a rule.
Intentric design principleBring your security review.
We will walk your team through approval boundaries, access handling, what we record and what we hold about your people — before you connect anything real.