How it works
From "something changed" to "here's why, and it checks out."
Nakana runs every change through four steps. The output is one record per change: what changed, who really made it, what caused it, and whether that reason holds up.
Step 1 · Observe
Collect every change in one format
Nakana reads changes from the systems that already record them, and adds a lightweight collector where nothing does.
- API integrations for cloud audit trails (CloudTrail, Azure Activity Log, GCP Audit Logs), Kubernetes audit logs, Git hosts, CI/CD, ITSM and SaaS admin logs. Read-only credentials.
- Log pipelines you already run. Pull from Datadog, Splunk, Elastic or your SIEM instead of collecting twice.
- Host collector for Linux (eBPF and auditd) and Windows (Event Log and Sysmon): files, packages, services, users, sudo, kernel modules, registry.
- Database audit from native audit logs: DDL, grants, roles, parameter changes.
- Network config via syslog, config archives and SSH/NETCONF snapshots, turned into line-level diffs.
Step 2 · Attribute
Find the person behind the account
Changes are often made by a service account, a shared admin login or a pipeline. Nakana follows the chain back to a human.
- Identity provider (Okta, Entra ID, Google Workspace): who signed in, from where, with which roles and MFA.
- HR directory (Workday, BambooHR, Rippling): team, manager, location, start date, leave.
- Privileged access (CyberArk, BeyondTrust, Delinea, Teleport, HashiCorp Vault): who checked out which credential, when, and for which ticket.
- On-call (PagerDuty, Opsgenie): who was on call and which incident was open.
- Pipelines: the person who merged, approved or triggered the run that made the change.
Step 3 · Explain
Link the change to what caused it
Nakana builds a chain of evidence for each change and writes the reason in a sentence a human can read in an audit or an incident.
Step 4 · Judge
The signals behind every verdict
Each change gets a verdict: explained, partly explained, or no reason found. The verdict shows the signals that drove it, so a reviewer can agree or overrule in one click. Overrules teach the baseline.
Is there a reason on file?
- Matches an approved change request
- Inside the request's approved window
- Touches only the systems the request names
- Standard change template applies
- Linked incident justifies an emergency change
- Made during a declared change freeze
Did it come through the front door?
- Traces to a merged commit and pull request
- Pull request had the required reviews
- Built and deployed by the expected pipeline
- Artifact is signed and provenance matches
- Hand edit on a Terraform or GitOps-managed resource
- Drift from the declared desired state
Is this normal for this person?
- Outside this person's usual working hours
- From an unusual location, network or device
- First time this person has made this kind of change
- Unusual for this person's team and role
- Person is on leave, departing or newly hired
- Approver and author are the same person
How much power was used?
- Break-glass, shared or dormant account used
- Privilege raised just before the change
- Change grants access or widens exposure
- Audit logging or monitoring turned off
What else was happening?
- Open incident on the same service
- Several related changes across systems in minutes
- Change reverted soon after
- Matches a known-bad pattern
What happens to a flag
- Ask the person in Slack or Teams, record the answer
- Open or update a ServiceNow or Jira record
- Send to your SIEM or SOAR with the evidence chain
- Retroactive change request for emergency fixes
Questions
What security and platform teams ask first
Does Nakana make changes to my systems?
No. Every integration is read-only. Nakana writes only where you tell it to: comments on change requests, messages to the person who made a change, and events to your SIEM.
Do we need a new agent everywhere?
No. Cloud, Kubernetes, Git, CI/CD, ITSM and identity sources connect by API. The host collector is only for servers where you want file, package and kernel-level detail you don't already ship to a log platform.
How does it decide what's normal for a person?
From their own history and their peer group: when they work, where from, which systems they change and what kind of changes they make. New staff start from their team's baseline.
Where does the data live?
Our plan is a hosted service in the US or EU, with a self-hosted option for regulated environments. Design partners help us decide what ships first.
What about AI?
Correlation and scoring are deterministic and auditable. Language models only write the plain-English summary, and every sentence links back to the evidence it came from.
See your own changes explained.
Design partners get a working view of one environment, such as one cloud account and one cluster, in the first weeks.