You are considering giving a security company access to your cloud. Here is precisely what that means, what it cannot mean, and what we have not built yet.
Enforcer is not software-as-a-service. It installs as an appliance inside your own infrastructure — your account, your hardware, your network. There is no Enforcer backend for it to send anything to, and the licence is verified offline, so it does not call home to check whether it is allowed to run.
Your findings, your evidence records, and the database holding them stay on the machine you installed it on. We cannot see them. Not because of a policy commitment or a data-processing agreement, but because there is no network path from your appliance to us.
A read-only IAM role: 71 permissions across 24 services. Every one is a List, Get or Describe against configuration. Not one of them can mutate anything, and not one can read a data plane.
The policy document is generated from the adapter source — from the API calls the code actually makes — rather than written by hand. If an adapter ever adds a call that is not in the policy, the build fails. Read it before you grant anything.
These actions are absent from the policy, and a build check fails if any of them is ever added. Enforcer can see that a bucket exists and how it is configured. It cannot see what is inside it.
| Not granted | So we cannot see |
|---|---|
| s3:GetObject | The contents of your buckets |
| secretsmanager:GetSecretValue | The value of any secret |
| ssm:GetParameter | The value of any parameter |
| dynamodb:GetItem / Scan / Query | Any row in any table |
| kms:Decrypt | Anything encrypted with your keys |
Every check ships in monitor-only mode. In its default state Enforcer cannot alter a single resource in your account, and the read-only role above means it could not even if the code tried.
To apply a fix, two independent things must happen: the specific check must be switched out of monitor-only, and a named person must approve that specific fix. Neither is a default, and neither alone is sufficient. The finding, the approval, and the fix are stored as one linked record.
Every vendor has this list. Most keep it in an internal document and let you discover it during procurement. Ours is here.
Enforcer is a single-node appliance. There is no database replica and no automatic failover. If the node dies, you restore it from backup. This is a deliberate trade-off at this stage, and the first thing we would change for a customer who needs it.
Zero, as of today. We are seeking that review before we seek customers, and we will publish the verdict whichever way it goes. Anyone telling you their evidence is "auditor-approved" should be asked which auditor, and to see it in writing.
We have not commissioned one. The appliance is hardened — immutable OS with no shell or package manager, admin access only through an authenticated API, one exposed port, database never published — and none of that is a substitute for someone competent trying to break it.
Enforcer checks your systems against ISO 27001. Enforcer itself is not ISO 27001 certified, not SOC 2 certified, and has no trust-centre badges to show you. A pre-revenue company claiming otherwise would be telling you something useful about itself.
Enforcer-CCA is registered in Mumbai, Maharashtra, India. It is bootstrapped and, at the time of writing, a single founder. If your procurement process requires a vendor with a support organisation, a certification portfolio, and a balance sheet, we are not that vendor yet, and we would rather you learn it from this page than from a questionnaire six weeks in.
What you would get instead: the person who wrote the code answering the phone, and a product whose evidence you can take with you — plain ZIP, plain JSON, plain CSV — the day you decide to leave.
