How it works

A request goes in. A change you can defend comes out.

Four steps, and a person is one of them. This is the whole shape of it from where your team sits — no hidden path, no step that runs itself because it seemed safe enough.

01 Describe Someone on your team says what they need in plain language — the service, the size, the region, the constraints that matter. No vendor tooling to learn first.

02 Review It comes back as one specific change: what gets created, what it will cost, what it touches, and whether anything is at risk. Already measured against your rules.

03 Approve A named person authorizes it. Anything that deletes or replaces live infrastructure requires elevated sign-off — always, and not as a configurable default.

04 Verify Once applied, what is running is checked against what was asked for. Then checked again, on a schedule, for as long as it exists.

Step 02 — Review

You are approving a change, not a description of one.

The most common failure in this category is subtle: you read a summary, you approve the summary, and something adjacent to it runs. Here the thing you reviewed is the thing that executes. There is no interpretation step between your yes and the work.

What it creates, changes or removes — stated plainly, before you decide
What it will cost, checked against the ceiling you set
Whether anything existing is replaced or destroyed, called out rather than buried
Change the request and the previous approval does not carry over

Step 03 — Approve

A well-worded request is not an argument.

Your rules are evaluated against what the change would actually do, not against how persuasively it was requested. Rewording it does not produce a different answer, and there is no phrasing that talks its way past a limit.

Spending limits and permitted regions are applied before a person is asked to look
No automated identity can stand in as the approver
Destructive changes require elevated sign-off regardless of any other outcome
Approvals and refusals are both recorded, with who and when

Step 04 — Verify

Verification does not stop at the first successful change.

A change that reports success has told you the request was accepted. It has not told you that your infrastructure matches what you asked for, and it certainly has not told you it still will next month.

✓

Confirmed at the time

What is actually running is compared against what was requested. A change is not finished because a command exited cleanly.

↻

Checked from then on

Infrastructure moves — someone edits a setting in a console, a vendor default shifts. Ongoing checks notice when reality has quietly stopped matching your intent.

→

Corrected the same way

When something has drifted, Intentric prepares the correction and waits. A correction is a proposal that goes through the same approval as the original request. It is never applied on its own.

Throughout

What holds true at every step.

These are not features you enable. They are properties of the way the thing works.

Access

No AI agent ever holds standing write access to your cloud
Access is granted narrowly, for one approved job, and expires with it
Nothing runs under a shared, permanent service account
The moment access is granted is itself part of the record

Record

Who asked, who approved, what changed and what resulted — recorded as it happens
Nothing is reconstructed from logs after someone starts asking questions
Records are written to be read later: exportable, and readable by people who were not there
Refusals are recorded as carefully as approvals

Reading about it only gets you so far.

Bring a change your team is currently putting off, and we will walk through what the reviewed version of it looks like.

Request Access See a worked example