Standard infrastructure code out. Nothing you can't open.
You are probably the person who gets asked whether this is safe to adopt. So here is the part that matters to you: what Intentric produces is ordinary, readable infrastructure code in the format your team already reviews — not a proprietary artifact that only works while you keep paying us.
You can read what it is about to do.
A platform you cannot inspect is a platform you should not run. Before anything reaches your account you can see the change in full — what it creates, what it costs, what it touches — and stop at that point for any reason or none.
After it runs, you can export the infrastructure code it produced and keep it. It is standard, it is inspectable, and it works without us.
The output is conventional enough that reviewing it is a normal Tuesday for anyone on your team who already reviews infrastructure changes.
# A managed Postgres database, highly available,
# 100 GB, in eu-west-1 — as approved.
resource "aws_db_instance" "app" {
engine = "postgres"
engine_version = "16.4"
instance_class = "db.t4g.medium"
allocated_storage = 100
multi_az = true
storage_encrypted = true
}Illustrative. Ordinary infrastructure code — no wrapper, no proprietary syntax, nothing that needs Intentric to run.
Straight answers, in the order they usually come up.
Can an AI change our infrastructure without a human?
No. Every change is authorized by a named person before it is applied, and anything that deletes or replaces live infrastructure requires elevated sign-off. Automation — including a correction proposed after drift is detected — can propose a change and nothing more. There is no configuration that grants it approval.
What happens to our access keys?
Nothing holds a permanent key to your account. Access is granted after a change is approved, scoped to that work, and expires when the job ends — successful or not. There is no shared, long-lived service account sitting behind this.
Are we approving a summary or the real thing?
The real thing. Approval attaches to the exact change you reviewed. Alter it and the previous approval does not carry over — you review the new one.
What happens to infrastructure we already have?
It stays where it is. You choose what comes under management and when, starting with whatever is least frightening. Nothing is adopted or altered because it happened to be in the account.
Does this fight with our existing tooling?
It sits upstream of it. Because the output is standard infrastructure code, the orchestration and state tooling your team already runs keeps working — Intentric produces the thing those tools were built to run.
What if we leave?
You export the infrastructure code and carry on. You lose the workflow — the requesting, reviewing, approving, verifying and record-keeping. You do not lose your infrastructure, and you do not need our permission to keep running it.
Is a successful apply treated as success?
No, and this is a real distinction. A change that reports success has told you the request was accepted. What is actually running is separately checked against what was asked for, and checked again on a schedule afterwards.
You keep working the way you work.
- Infrastructure that lives in your repositories keeps living there, in sync
- Separate environments carry separate parameters and separate stakes
- Your own automation gets machine access, held to exactly the same rules as a person
- A command-line tool, for the people who would rather not use a browser
What is real today.
- AWS is live and complete. Azure and Google Cloud are roadmap, not shipped
- We are early, working with a small number of design partners
- What you ask for genuinely changes what gets built next — that is true now and will not be later
- We will tell you which is which before you commit to anything
Ask us the hard version of any of those.
We would rather answer it now than have you find out during a security review.