How we touch your systems, and how you stay in control.

Access: the least we need, for as long as we need it

• Read-only by default. Every connection starts with access that can look but not change. Rights to change a system are requested separately, explained in plain words, and approved by you.
• Keys stay in a vault. Access keys you share go straight into an encrypted vault. Each piece of work gets a single-use lease on the one key it needs, tied to that job, and the lease ends with the job.
• Narrow on the server. On servers, our agent accepts only a fixed list of named actions. There is no open shell, and a read key cannot be used to write.
• You can withdraw it. Any access can be revoked from your portal at any time.

Changes: nothing happens without your approval

• Every change is a written plan: what will change, why, the risk, how it will be undone, and the check that will prove it worked.
• Only the approvers you name (owners and admins in your portal) can approve. Our own team can never approve its own work.
• Work can only come from a fixed catalogue of actions with checked parameters. Nothing typed into a request, a log line or an email can add a new kind of action.
• Anything that touches money, payments, accounts, keys or a security incident goes to a person, never to an automatic fix.

Proof and rollback

• Before a change, the current state is saved.
• After it, a check runs. If the check is red, the saved state is put back automatically and a person takes over.
• A request can only close when an independent check, run separately from the work itself, comes back green. Nobody can mark a request done by hand.

The activity record

Every look, decision, approval, start, result and check is written to an append-only record. Each entry is chained to the one before it, so an edited or deleted entry shows. You can download the whole record for your company from the portal at any time, and we keep it for at least a year.

How AI is used

Olodu's engineers are AI models working inside these rules, reviewed by a second model from a different provider and supervised by people. The models read evidence and choose from the catalogue of allowed actions; they never hold a key and never run anything themselves. Lines that look like passwords, keys or tokens are removed from evidence before any model sees it. When the two engineers disagree, or confidence is low, the request goes to a person.

Your data

We process your data only to do the work you ask for, under a data processing agreement. Our data processing terms set out the security measures, the subprocessors we use, 48-hour breach notice, and deletion when the service ends.

Where we are

We are a young service and would rather say so. We are not yet SOC 2 audited; we are building towards a Type I report, and Department plans include preparing your own SOC 2 evidence. If your security team has a questionnaire, send it with your request and we will answer it in writing.