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. It pulls with read-only credentials by default, and takes pushed events where a source offers them. No agent on your servers.
- 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 and kernel events (auditd, eBPF, Windows Event Log, Sysmon, EDR telemetry) read from the log platform or EDR you already run. An optional collector covers hosts nothing else sees.
- One relay for private networks. Network devices, on-prem databases and self-hosted tools sit behind a small relay container that makes outbound-only HTTPS connections.
- 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.
- Vulnerability context from the scanners you already run (Dependabot, Snyk, Wiz, Inspector, Defender and others) plus CISA KEV, FIRST EPSS and Chainguard's advisory feed. Nakana doesn't scan.
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
- Touches a library or host with a known CVE, flagged harder if it's on CISA's exploited list
- The change is a fix for a CVE, which counts as its reason
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 an agent?
No agent on your servers. Cloud, Kubernetes, Git, CI/CD, ITSM and identity sources connect by API. Host and kernel events come from the log platform or EDR you already run. Systems that aren't reachable from the internet, like network gear and on-prem databases, go through one small relay container that only makes outbound connections. An optional collector exists for hosts nothing else covers.
Do we push data to Nakana, or does it pull?
Nakana pulls by default with read-only credentials, so you can start without changing anything. Where a source can push events (webhooks, CloudTrail through EventBridge, Kubernetes audit webhooks, syslog), Nakana takes them in seconds. The only data Nakana sends out is what you ask for: verdicts on change tickets, questions in Slack or Teams, events to your SIEM. How each integration connects
Is Nakana a vulnerability scanner?
No. It reads the findings your scanners and EDR already produce, plus public feeds like CISA KEV and EPSS. When someone changes a service, image or host that carries a known exploited vulnerability, Nakana tells them in the change record. When a change fixes a CVE, that fix becomes the reason.
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.