No credentials where the model runs.
AI roles work in an isolated sandbox with no cloud, source-control or database credentials and no outbound network.
Governed delivery · AWS · Azure · Google Cloud · On-premises
Ship the change. Keep the evidence.
Butai is SHINRAI’s governed delivery platform. Fixed tools check every change. A named person approves every decision that matters. Every engagement ends with a signed record your risk team can verify without taking our word for it.
- Fixed fee for the result
- Named human approvals
- Signed, verifiable evidence
| seq | to_state | actor | hash |
|---|---|---|---|
| 01 | intake◆ intent accepted | human:owner | 9f2c…a41 |
| 02 | baselineexisting estate measured | agent:architect | 1b7e…0c9 |
| 03 | plangap closure, 0 destroys | agent:architect | c44d…7e2 |
| 04 | buildno credentials | agent:builder | 58aa…913 |
| 05 | verifychangeset computed by engine | executor:iac.plan | e0b1…5f6 |
| 06 | plan approved◆ plan sha256 bound | human:owner | 3d90…b27 |
| 07 | verifyexact plan applied | executor:iac.apply | 7c1f…d08 |
| 08 | reviewsecond model family | agent:reviewer | a6e3…441 |
| 09 | recordevidence pack, in-toto | agent:recorder | 0f5b…cc2 |
| 10 | shipped◆ signed | human:owner | b81d…3a7 |
- AWS Advanced Tier Services Partner
- Snowflake Select Partner
- Informatica IDMC Partner
- Nairobi · Dubai
Why Butai exists
Building got cheap. Trust did not.
AI writes code for any platform in minutes. Your risk function still asks the questions it has always asked, and a chat transcript answers none of them.
Who decided this?Every decision that matters is made by a named person and recorded with their identity and the time.
What was checked?Fixed tools run the contract’s checks in a fixed order: validation, lint, policy-as-code, static safety and plan review. No agent can skip one.
What changed?The engine records every change from the repository itself, with hashes before and after. The plan you approved is the only plan that runs.
Can we verify it ourselves?Yes. The record is signed in open formats. Your auditor checks it with open-source tools, a published key and your own audit log.
How a sprint runs
Eight steps. Nobody marks their own work.
tools and AI roles, inside fixed limits a decision only a named person can make
Every sprint follows the same path. Each step has one actor, and whoever produces the work never approves it. The code can come from Butai’s agents, your cloud provider’s generator or your own engineers; it is checked the same way.
- 01humanintakeOwner
Accepts the intent and its acceptance criteria. Nothing starts without them.
- 02baselineArchitect
Measures your estate as it is today, including what already exists, so the result can be compared with it.
- 03planArchitect
Writes the plan, the data it touches and the checks it must pass. Personal data or a production control sends the sprint to a risk hold for a named person.
- 04buildBuilder
Produces the code in a sandbox with no credentials and no network. The engine, not the builder, records what changed.
- 05verifyExecutor · Verifier
Fixed tools run every required check in a fixed order. The Verifier reads the results. It cannot change a check or skip one.
- 06humanapprove planOwner
Approves the exact change plan by its digest, with the number of resources it may create, import, change or destroy.
- 07reviewReviewer
Audits the change against your original intent, on a different AI model family from the one that built it.
- 08humanrecord · shipRecorder · Owner
The evidence pack is assembled from the ledger. The Owner reads it and signs the ship approval.
Repair loops have limits.A failed check goes back to the Builder with the exact finding. If the same failure repeats, or after three loops, the sprint stops and asks the Owner.
Blocked means a person decides.Only the Owner can clear a blocked sprint. No agent and no timer can.
An outage is not a decision.If the approved model route is down, the sprint waits and resumes by itself. It never switches to an unapproved region.
Regulator lens
Your regulator’s questions, already answered.
Each evidence pack maps its records to the rules your institution answers to. Choose a regulator to see what it asks and where the pack answers it.
Central Bank of Kenya
Prudential Guideline on Outsourcing and the Cybersecurity Guidance Note.
| What it asks of your institution | Where the pack answers it |
|---|---|
| Access to records and the right to audit, for you and for the regulator | Read-only access for your risk and audit teams, and a full export of every pack, the ledger extract and the keys to verify them |
| Approval of sub-contractors | An engagement register of every model provider, region and route used, with your approval reference and a log of notified changes |
| Your data kept separate from other clients’ | Every record tied to your institution in the database itself and encrypted with your own key; no standing SHINRAI access |
| Continuity and exit | Export on demand, deletion on your schedule and a signed proof for every deletion |
| Incident notification | An incident record with the timeline and affected engagements, within the notice period in your contract |
Office of the Data Protection Commissioner
Kenya Data Protection Act 2019 and the Commissioner’s guidance on cross-border transfers.
| What it asks of your institution | Where the pack answers it |
|---|---|
| An impact assessment before high-risk processing | Personal data in scope sends the sprint to a risk hold; building starts only after your DPIA confirmation is on file (02b-dpia-confirmed.md) |
| A record of each cross-border transfer: date, recipient, purpose and description of the data | A transfer record in the pack for every movement of your data out of Kenya |
| Safeguards for processing and transfers | Encryption, multi-factor access and audit logging, listed for the engagement |
| People not subjected to purely automated decisions | A named human approval of every consequential action, with identity and time |
Central Bank of the UAE
The 2026 guidance note on AI and machine learning, and the Outsourcing Regulation.
| What it asks of your institution | Where the pack answers it |
|---|---|
| Effective human oversight of AI | An autonomy declaration in every pack: which actions need a named approval, which are automatic checks and which are never performed |
| Transparency and explainability | Plain-language findings for non-technical readers, alongside the technical record |
| An inventory of third-party models | Every model, version and provider used in the engagement, recorded in the pack’s provenance |
| Prior approval for processing data outside the UAE | The processing location of every model call, recorded; routes agreed with you before any of your data is used |
Saudi Central Bank
Rules on Outsourcing.
| What it asks of your institution | Where the pack answers it |
|---|---|
| Unrestricted access for the regulator | Reader access and a complete export, including the keys needed to verify it |
| Non-objection for outsourcing outside the Kingdom | Processing locations recorded for the engagement, ready for your submission |
| Contingency plans and exit rights | Export, continuity and deletion procedures, each with a signed proof |
Digital Operational Resilience Act
Article 30 contractual provisions for ICT services to EU financial entities.
| What it asks of your institution | Where the pack answers it |
|---|---|
| The locations where data is processed, with notice of changes | Processing locations and a change log in every pack |
| Conditions for subcontracting, and notice of material changes | The sub-processor register with your approval and every change notification |
| Audit, access and inspection rights | Reader access, full export and verification with open-source tools |
| Exit strategies and return of data | Full export and signed deletion proofs |
ISO/IEC 42001
For organisations running an AI management system.
| What your controls ask for | Where the pack answers it |
|---|---|
| Records of AI system use and human oversight | Approvals, role outputs and model versions in the ledger |
| Transparency about AI-generated content | Every pack states which parts were written by AI |
| Controls over AI suppliers | The model register and route policy for the engagement |
Mappings show which records support each requirement for your engagement, and are confirmed with your compliance team during scoping. Your internal control set can be added in the same way. A mapping supports your assessment; it does not certify compliance.
Evidence
Every sprint ends with a record, not a summary.
engagements/your-org/sprint-0007/
├── 00-intent.yaml ◆ owner
├── 01-baseline.json
├── 02-plan.yaml
├── 03-change-claim.json # the builder’s account
├── 03-changeset.json # computed by the engine
├── 04-verification.json # 9 checks, results parsed
├── 04c-plan-approval.json ◆ plan sha256
├── 05-review.json
├── 06-evidence-pack.json ✓ signed
├── 06-evidence-pack.pdf
├── 07-cost.json
└── attestations/ # in-toto, DSSE
$ cosign verify-blob-attestation \ --key shinrai-evidence.pub \ --type https://shinraitechnologies.io/butai/evidence-pack/v1 \ --signature pack.dsse.json \ 06-evidence-pack.json Verified OK
The evidence pack is built from the ledger, not written from memory. It holds the intent, the plan, every change and who made it, every check and its result, every waiver and who granted it, the before-and-after measurement, the cost, and the version of every model, prompt and contract involved. It says which parts were written by AI, and who is responsible for each control: your cloud provider, SHINRAI, you, or shared.
It is signed in the open in-toto and DSSE formats, so anyone you allow can check it with open-source tools and our published key. You never need our software to trust our work.
| Document | Who issues it | What it is |
|---|---|---|
| Evidence Pack | Butai, at ship approval | A first-party record with verifiable integrity and provenance. Included in every sprint. |
| SHINRAI Delivery Attestation | A SHINRAI Governor, by hand | A separately signed statement with a defined scope, reliance limits and a withdrawal method. Optional. |
| Independent assurance | Your external assessor | Their opinion, in their framework. Butai gives your assessor the record and the keys. |
A signature proves the record is intact and where it came from. It does not prove that a control is effective or that anyone is compliant. We say so on every pack.
Controls
Controls your security team can inspect.
Six controls sit between the AI and your environment. Each one can be tested by your security team, and each test is recorded.
Signed instructions only.
The component that touches your environment accepts only signed, short-lived, single-use instructions bound to one client, environment, region and plan. It cannot run a free-form command.
The plan you approved is the plan that runs.
Apply uses the stored plan by its digest. A different plan, a re-plan or a destroy count above your limit is refused.
Your environment, your audit trail.
We act only through an identity you create and can revoke on your own. Every action carries a session name you can find in your own audit log.
One client at a time.
Every record is tied to one client in the database itself. SHINRAI staff have no standing access to your data. Support access is time-boxed, approved by a second person and visible to you.
Model calls stay inside an approved boundary.
Model calls run only on routes your engagement approves, by default Amazon Bedrock in EU regions with global routing blocked. The law that applies to your data is recorded for your engagement, not assumed.
Where we work
Any environment. Any industry. One method.
The contract, the approvals, the ledger and the evidence pack are the same wherever your systems run. What changes is the tooling that checks the work and the audit log you check it against.
| Environment | Change defined in | Checked with | You verify against | Our access |
|---|---|---|---|---|
| AWS | Terraform, CloudFormation | Policy-as-code, AWS Config rules, plan review | AWS CloudTrail | An IAM role you create and can revoke |
| Microsoft Azure | Terraform, Bicep | Policy-as-code, Azure Policy, plan review | Azure Activity Log | A service principal you create and can revoke |
| Google Cloud | Terraform | Policy-as-code, Security Command Center, plan review | Cloud Audit Logs | A service account you create and can revoke |
| On-premises · private cloud | Terraform, Kubernetes manifests, configuration code | Policy-as-code, configuration baselines | Your SIEM or platform audit log | A scoped account you create and can revoke |
Industries
Butai is for any organisation whose technology changes have to be explained to someone: a board, an auditor, a regulator, a customer or its own security team. Regulated organisations need the record most, so the controls are built to their standard. Everyone gets work that was checked by someone other than the person who built it.
Technology & SaaSFinancial servicesInsuranceHealthcarePublic sectorRetail & e-commerceLogistics & mobilityTelecoms & mediaManufacturingEnergy & utilitiesEducationReal estate
Engagements
Any kind of work. A defined scope every time.
The range of work is open; each engagement’s scope is fixed. Every engagement starts from a contract that says what will be produced, how it is checked, what it may touch and what done means. That is what lets us fix the price, and what lets your risk team read the result.
Flagship engagement
The Landing Zone Sprint
The secure foundation every other workload sits on, on the platform you choose. New estates are built to the contract’s target. Existing estates get a gap-closure plan, with every imported resource approved line by line and nothing destroyed.
New estateExisting estateAWS · Azure · Google Cloud · On-premises
Organization root SCP baseline
SecurityLog archiveAudit
InfrastructureNetworkShared services
WorkloadsProductionNon-production
SandboxExperiments
guardrails, logging and identity applied by the contract imports approved by the Owner
Included
- The implemented foundation, defined as code: account, subscription or project structure, guardrails, logging, identity and network baseline
- Verification results for every required check
- The signed Evidence Pack, mapped to your regulator and readable by your risk team through their own login
- A baseline measurement and the comparison after delivery
Options
- SHINRAI Delivery Attestation, issued by a SHINRAI Governor
- Assurance Refresh, quarterly or annually
- Delivery in your own environment, after the client deployment gate
You provide
- A named technology owner and a named risk or security reviewer
- Administrative control of the target, such as an AWS Organization, an Azure tenant, a Google Cloud organization or your on-premises platform
- Your data classification and accepted processing regions
- Review and acceptance of the Evidence Pack
Not included
- Production changes in the first engagement
- Workload migration, which is a separate engagement
- Certification, audit opinions or any statement that you are compliant
- Regions outside your approved boundary
Fixed fee
Quoted after a scoping call, for a fixed scope. A premium applies when we work in your environment.
Rework
Rework within the agreed scope is at our cost.
Evidence
The Evidence Pack is a named deliverable in every engagement, not an extra.
No usage billing
You never pay for model usage, retries or tokens.
Assurance Refresh
Evidence starts to age the day a sprint ships. Assurance Refresh re-checks your deployed estate against the contract, quarterly or annually, with no changes made. Drift and failed controls are reported as findings. Each refresh issues a new signed version of the pack, linked to the original, so your auditors see a continuous chain.
Verify-onlyRead-only accessLinked pack versions
Other work, same discipline
Every SHINRAI engagement runs under the Butai method: a scoped contract, checks by someone other than the builder, named approvals and a signed record. On any cloud or on-premises.
Cloud migration and modernisation
Assessment, migration plan, cut-over and optimisation, with the before-and-after measured.
Data platforms and analytics
Data foundations, integration and reporting, including Snowflake and Informatica.
AI and machine learning
Models and AI features built with the same approvals and records as any other change.
Business applications
Application builds, integrations and SAP workloads, scoped into a contract before work starts.
DevSecOps and platform engineering
Pipelines, guardrails and security checks that keep running after we leave.
Backup, recovery and resilience
Recovery targets agreed up front and tested, with the test results in the record.
How Butai compares
Others sell the build. We stand behind the proof.
AI coding agents and infrastructure platforms make building faster. Butai makes the result defensible to the people who have to sign it off.
| Question | AI coding agents | IaC automation platforms | Cloud provider tools | Typical systems integrator | BUTAI By SHINRAI TECHNOLOGIES LIMITED |
|---|---|---|---|---|---|
| A named person approves each change | ◐Pull-request review | ●Approval before apply | ●Admin approval | ◐Varies by project | ●Plan approved by digest; ship signed by the Owner |
| Checks run by someone other than the builder | ◐Optional review agents | ●Policy-as-code | ◐Built-in guardrails | ◐Varies by team | ●Fixed checks, plus a reviewer on a different AI model |
| Evidence mapped to your regulator | ○Audit logs | ◐Run history | ○Activity records | ◐Documents written afterwards | ●Signed pack mapped to CBK, ODPC, CBUAE, SAMA and DORA |
| Verifiable without the vendor’s software | ○No | ○No | ○No | ○No | ●Open in-toto and DSSE formats |
| Works in your environment under your authority | ◐Self-hosted options | ●Yes | ●Yes | ◐Varies | ●Revocable identity and a co-signed deployment record |
| How you pay | Seats plus usage | Seats or managed resources | Tool is free; you do the work | Day rates or fixed price | A fixed fee for the result |
Based on public documentation for leading products in each category, October 2026. Individual products vary.
Where the work runs
First in a test environment. In yours only when you sign.
- 01 · SHINRAI test environment
Built and verified with us
We build and verify in a SHINRAI-controlled environment on the same platform as yours, dedicated to you, with synthetic or minimised data. For on-premises work, in a test environment you provide.
- ◆ client deployment gate02 · Your non-production environment
Moved into your estate
You create a small, readable access identity. Our release authority and your named authority both sign a deployment record for that environment, region and contract version.
- ◆ your change process03 · Production
Your change approval
A separate change through your own process, under a promotion contract that re-checks every waiver granted in lower environments.
Who stands behind it
SHINRAI is the firm behind the platform.
Butai is SHINRAI’s own delivery platform, and SHINRAI stands behind every engagement it runs. We are an AWS Advanced Tier Services Partner with offices in Nairobi and Dubai, delivering cloud, data and AI work for clients across industries.
AWS Advanced Tier Services PartnerSnowflake Select PartnerInformatica IDMC Partner
Founder & CEO
Timothy Munyao
Holds 13 AWS certifications and the AWS Golden Jacket, the first Kenyan to receive it. Leads Butai’s design and governance.
30%lower costs, about KES 1M saved a yearUnity Homes
40%fewer manual IT tasks, 20 hours saved a weekAdrian Group
83%faster deploymentsPallax Kenya
99.99%uptimePM Realty
Results from SHINRAI client engagements, as published on shinraitechnologies.io.
Fit
Who Butai is for.
A good fit
- Organisations in any industry whose technology changes must be explained to a board, an auditor, a regulator or a customer
- Estates on AWS, Azure, Google Cloud, on-premises or a mix of them
- A CIO, CTO or transformation owner who wants speed without giving up oversight
- A CISO, risk or audit function that will read the evidence
Not a fit
- Anyone looking for an autonomous agent to run unattended in production
- Projects that need a compliance certificate rather than evidence
- Work with no acceptance criteria anyone can check
- Engagements without a named owner who can make decisions
Questions
What teams ask first.
Is this autonomous AI?
No. AI roles draft, build and check inside fixed limits. Named people make the decisions that matter: accepting the intent, approving the exact plan, clearing a block, granting a waiver and approving the ship. Each decision is recorded with who made it and when.
Will Butai make us compliant?
No platform can. The Evidence Pack shows what was done and which of your controls the evidence supports, with who is responsible for each. Whether you are compliant is for you, your auditors and your regulator to decide.
Can our auditor check the evidence without you?
Yes. Every pack is signed in the open in-toto and DSSE formats. Your auditor verifies it with open-source tools such as cosign and SHINRAI’s published key, and can match every action to your own audit log.
Do you only work on AWS?
No. We work on AWS, Microsoft Azure, Google Cloud, on-premises and hybrid estates. The contract, approvals, ledger and evidence are the same on each; the checking tools and the audit log you verify against are the ones native to your platform.
Can you work with code from our own team or our cloud provider’s tools?
Yes. Code from your engineers or from your cloud provider’s generator goes through the same path as ours: the engine records what changed, fixed tools check it, a named person approves the exact plan and the evidence pack records it all.
Where is our data processed?
Model calls run only on routes your engagement approves, by default Amazon Bedrock in EU regions with global routing blocked. If your regulator requires processing in your country, we agree the route during scoping, before any of your data is used. Before processing begins we record the parties’ roles, the laws that apply, where your data subjects are, our sub-processors, the transfer basis and retention.
Can we stop you?
Yes. Revoking the access identity you created stops all work in your environment immediately. Butai holds the engagement and never switches to another credential, environment or region.
Who at SHINRAI can see our data?
No one by default. If an incident needs a look inside your data, a support session is opened for your tenant only, approved by a second person, read-only, limited to four hours and listed where your team can see it.
Is Butai only for regulated industries?
No. The controls are built to the standard regulated organisations need, because they need the record most. Any organisation that wants its changes checked by someone other than the builder and approved by a named person gets the same thing.
What happens to our evidence when we leave?
You can export every evidence pack, the ledger extract and the keys needed to verify them. Deletion follows the schedule in your contract, legal holds take precedence, and every deletion produces a signed proof.
Next step
Book a scoping call.
Tell us about your environment and the work you have in mind. We reply to arrange a 30-minute call.