Customer-authorised
Customers choose the cloud accounts, identities and permission scope available to Acumy. Access can be changed or revoked from the customer's own cloud control plane.
Trust & security
Customer control comes first.
Acumy is built for a sensitive position between infrastructure intent and cloud action. Customers control the connection, the permission scope and the workflows Acumy is authorised to operate.
Cloud access model Customer controlled
Customer cloud boundary
AWS Azure GCP
Customer-managed roleAccounts, scope and permissions defined by the customer
ACUMYGoverned control
DiscoverEvaluateAct
Provider-native identity Scoped, revocable access Decision record retained
Security principles
Control starts with the connection
Acumy does not require a shared human administrator account. Cloud access is established through provider-native identities and roles configured by the customer for the capabilities being enabled.
Scoped by workflow
Read-only discovery and authorised lifecycle actions are separate permission paths. Enabling visibility does not automatically grant Acumy permission to change infrastructure.
Metadata, not payloads
The core governance model uses cloud resource metadata and Acumy operating records. It does not require access to application payloads to evaluate ownership, policy, budget or lifecycle.
Data boundaries
Collect what governance requires
Acumy needs enough context to identify infrastructure, apply policy, assign accountability and interpret its lifecycle. The core platform does not need to inspect the business information processed inside a customer workload.
Exact data categories, retention requirements and enabled actions are documented during technical evaluation and reflected in the customer's connection scope.
Governance inputs
What the control plane uses
Resource and configuration metadata
Ownership, purpose and tag context
Budget and relevant cost signals
Requests, policy decisions and approvals
Outside the core requirement
What Acumy does not need
Application payloads
Customer database contents
End-user business records
Shared human administrator passwords
Auditability
Keep the reason alongside the action
A cloud event alone rarely explains why an environment was allowed to exist. Acumy retains the governance context around the decision so technical and financial reviewers can follow the Workspace lifecycle.
01Request identity
The initiating person, pipeline, workflow or AI agent.
02Policy decision
The controls evaluated and the allow, approval or block outcome.
03Approval and exception
Who approved a request, what changed and why an exception was granted.
04Lifecycle action
Provisioning, schedule changes, extensions, expiry and retirement activity.
Workspace decision recordCOMPLETE
Workspace · ATL-204Model validation environment
09:41Request submitted
AI workflow / Data Platform
09:41Eight controls evaluated
Approval required
09:44Request approved
Platform owner / 12-hour lease
21:44Retirement scheduled
Automatic lifecycle action
Beta transparency
Clear about where assurance stands
Acumy is currently in beta. Connection scope, permissions and data flows are reviewed with each design partner before access is established. We will not describe a certification or independent control assessment as complete until it has been completed and verified.
Start a security conversationProduction assurance programmeSOC 2 readiness Operational readiness Enterprise documentation
Formal control design, evidence collection and independent examination are part of the assurance roadmap. Acumy is not currently presented as SOC 2 certified.
Security testing, vulnerability management, incident response and customer notification processes form part of production readiness.
Data-processing terms, subprocessor information, retention and deletion commitments will be made available for production security review.
See Acumy in operation