Security
Trust & Security
Security should be understandable before access is granted, and verifiable after changes are made.This page sets out the access involved, what stays under your control, how changes are authorised, how results are recorded, and what we do and do not claim today.
Principles
How we approach security
Authorization before change
Nothing in a customer's cloud changes without approval from a named person in their organisation.Bounded remediation
Each change is scoped to the resource and the control it fixes, with a plan to roll it back.Verification, not assumption
A fix counts only when the check that found the problem passes on the same resource.Evidence and traceability
Checks, approvals and changes are recorded, so anyone reviewing the work can follow what happened.Least-privilege access
Checking uses read-only access. Changing needs a separate, narrow permission the customer grants and can remove.Cloud-aware engineering
AWS, Azure and Google Cloud each work differently. Controls are checked and fixed the way each cloud actually behaves.People decide what matters
Judgement on risk, priority and sensitive production changes stays with people, never with software alone.
Your control
Access you create, and can remove
Access is granted by you, in your own cloud account. We work toward the narrowest permissions each task needs.
What stays under your control
- Checking your controls needs read-only access.
- Applying a fix needs an additional, narrowly scoped permission for that one kind of change. You grant it only if you want Tricognita to apply fixes.
- Each kind of automated fix is off by default. It is switched on per organisation.
- Nothing changes in your cloud until someone with approval rights approves it.
How each cloud connects
- AWSARIALaunching
- A read-only IAM role you create in your account and can remove at any time.
- Microsoft AzureARIALaunching
- A service principal with the built-in Reader role.
- Google CloudARIALaunching
- A least-privilege service account. In active development.
Access and credentials
Connection uses a role or service principal that you create and own. Read-only is not the same as no access: on some clouds, read-only roles can read stored data. The permissions an engagement uses are agreed in writing before it starts.
Changes
How a change is authorised
Every change follows the same path. Your organisation authorises it; nothing runs without that approval.
01
Find
A defined check shows a control failing on a resource.
02
Scope
The fix is agreed: what changes, on which resource, and how to roll it back.
03
Authorize
Someone with approval rights in your organisation approves it.
04
Bounded change
One setting changes on that one resource, and nothing else.
05
Verify
The same check runs again, and the result is recorded.
Rules every change follows
- Nothing changes in your cloud until someone with approval rights approves it.
- An approval is valid for a limited time. After that, it must be approved again.
- A fix changes one setting on the one resource that failed. It cannot be pointed at anything else.
- After a fix is applied, the control is checked again straight away.
- Each fix ends in one of three outcomes: Fixed, Did not fix it, or Unconfirmed.
Automated fixes, by cloud
ARIALaunchingIn development- Customer-authorised fixes on Azure
- Supported automated fixes are available by enablement for supported controls, subject to customer authorization.
- Customer-authorised fixes on AWS
- The same bounded, approved fix model on AWS, for a narrow set of supported actions.
- Tracking for fixes your team applies
- Where no automated fix applies, your engineers make the change and it is verified the same way.
Evidence
What changed, and what the check returned
Verification establishes what changed and what the relevant check returned. Records are signed and linked.
How checks and records work
ARIALaunchingIn development- Each control is checked by a defined rule. AI does not decide whether a control passes.
- If a control cannot be checked, we say so. It is never counted as passing.
- Every check is saved as an evidence record: the control, the resources, the time and the result.
- Each evidence record is signed and linked to the one before it.
- When a record is opened, the product checks it still matches what was written.
- Tricognita verifies each record's integrity.
- Every request, approval and change is recorded in a linked audit log.
Your data
Data handling
- The platform evaluates cloud configuration and control results.
- Access uses read-only roles you create and can revoke at any time.
- Where data is stored and processed is set out in writing for each engagement.
The platform
Access inside ARIA
These controls are built into the platform, and are confirmed in production before client access opens.
Roles and separation
ARIALaunchingIn development- Give each person the access they need: administrators, security operators, and read-only auditors.
- Invite your auditor with a read-only role. They can see controls and evidence, and cannot change anything.
- Each organisation's data is kept separate.
What we publish
Public proof
We have no customer case studies, audit reports or penetration test reports to publish yet. When a customer approves publication in writing, it will appear here.
Tricognita does not yet hold a SOC 2 or ISO 27001 certification.
Contact
Security contact
Report a security issue
Found a security issue in Tricognita? Email security@tricognita.com with the details. Please give us reasonable time to fix it before disclosing it publicly.
Service and account questions
Email contact@tricognita.com, or use the contact form.
Transparency
What we claim, and what we do not
Everything above is documented, and each capability shows its current state. The following are not claimed today.
- That read-only access cannot read any of your data: on some clouds, read-only roles can read stored data.
- Two-person approval for changes.
- Published hosting locations, or data residency in a particular country.
- Company certifications, audit reports or penetration test reports.
- Encryption commitments beyond what is documented for each engagement.
The software
ARIA
Cloud control remediation and verification
ARIA carries the repeatable cloud-control work under the rules on this page. People keep every decision.
01
Evaluate
02
Fix
03
Verify
04
Keep secure
05
Evidence
Questions about access or approvals?
A scoping call covers the access an engagement needs and how changes will be authorised, before any work starts.