IntegraTrace · Platform Whitepaper
The Internal Risk Identity Platform
Identity is the modern perimeter, and most of the tools guarding it still read lists. IntegraTrace fuses what every identity can do, what has happened to it, and what it actually does — across every cloud, in one risk model. This paper describes that platform, and shows it running against two live cloud environments.
Every organization now runs on identities it cannot see: human and machine, spread across clouds, holding privileges nobody remembers granting. A list of those identities is not a model of the risk they carry — and the gap between the two is where breaches live.
Everything below is the output of pointing IntegraTrace at two real, in-use cloud environments and letting every layer run: continuous inventory capture, deterministic rule checks, multi-angle graded assessments, a cross-environment identity graph, and an automated insight pass over the change history. Every claim is grounded in a specific record the platform can point back to. Where it isn't, we say so.
01 Why now
The perimeter is now a directory
Machine identities outnumber the humans they serve. Privileges accumulate faster than any review cycle retires them. And every breach post-mortem of the last decade reads the same way: a credential, a role, and a short chain nobody had drawn — not a firewall.
Entitlement inventories are easy to produce and hard to act on. A list of 76 identities and their role bindings is technically complete and practically useless: nothing in it says which of those identities can reach the others, which ones nobody owns, or which two are the same identity wearing different names. And a new population is arriving that lists cannot describe at all — AI agents operating with production credentials, holding entitlements indistinguishable from a human's.
The Internal Risk Identity Platform is built on one premise: identity risk is only legible when three views of every principal are held together — what it can do (entitlements, continuously captured), what has happened to it (every change, as a sequence), and what it actually does (behavior, with evidence). Each view alone produces a report. Together they produce a model.
02 One model
Every cloud, one blast radius
Run two cloud environments through separate tools and you get two reasonable reports. Neither contains the observation that matters most: the two clouds fail the same way.
- The same anti-pattern, twice. An identity with the authority to grant authority —
AdministratorAccessin one cloud,projectIamAdminin the other. Different vocabulary, one control gap, one remediation pattern. - The same blind spot, twice. Trust conditions absent on federated roles in one cloud; trust relationships entirely unrecorded on service accounts in the other. In both, the privilege side of the model is well populated and the reachability side is thin.
- One privileged population, not two. The 50%-privileged figure is an organization-level number. Neither cloud produces it alone — and it is the number a security lead is actually accountable for.
The platform's identity graph is what makes those observations possible: 158 nodes and 173 edges built from both environments' captures, findings and audit trails, held as one structure and explored as one — live in the product, filterable by privilege band and time window, every node resolving to its underlying records.
03 Analysis
Findings you can replay, assessments that show their work
The platform's first analytical layer is deterministic: rule checks that run on every capture and never ask a model anything. The second is judgement: each environment is examined from four independent angles — escalation, trust boundaries, duplication, dormancy — through a multi-step analysis that normalizes the environment, reads it from two directions, and synthesizes a single graded assessment. The clearest results from the field study show why both layers exist.
CriticalA compromised instance yields three independent sets of administrator credentials
Three lifecycle roles — -deprovision, -maintenance, -provision — carry byte-identical grants and byte-identical trust. Each holds unconstrained AdministratorAccess. All three are assumable by exactly one principal: a single EC2 instance role, trusted with no condition recorded.
Read as three rows in an inventory, these are three ordinary CI roles. Read as a graph, they are one door with three handles — and no lock. The assessment's own phrasing: the name-suffix separation is "nominal rather than enforced", and the instance role is "a single point of failure".
CriticalA three-step chain from one service account to project owner
Each grant is defensible in isolation. The combination on one identity is the escalation. No single role in that list would fail a review; the set fails immediately once you ask what it can do in sequence.
The assessments treat reachability as a separate question from privilege, and that split is where the sharpest result came from: in the GCP project, the trust relationships of all five IAM-mutating identities were unrecorded — not permissive, unknown.
"…leaving the reachability of every path — including those starting from the broadest IAM-mutating grants in the project — unverifiable and therefore uncontrolled."
Assessment · privilege escalation · GCP environment
A tool that only reads grants would have rated these accounts by blast radius and moved on. Separating "what can it do" from "who can become it" turns a confident severity score into an accurate one.
04 Depth
What a list cannot say
Two human users hold AdministratorAccess twice over — directly attached and inherited from a group. Removing either path leaves the access intact, which is exactly why neither gets removed: each is individually safe to keep and collectively impossible to audit. The assessment is specific about which to drop: keep the group-inherited grant, remove the direct attachment, and apply permission boundaries so that admin cannot extend itself. The same duplication appears between machine identities: two scanner roles with materially identical grant sets, differing only in a name suffix, flagged as an overlapping pair with the right question attached — does the second exist for a reason?
It flagged our own role. One of those two scanner roles was created by this exercise — the read-only role the platform assumes to inventory the account. It was picked up as duplication of an existing scanner role within minutes of being created, on evidence, without anyone telling the platform it was new. We are leaving the finding in the report rather than filtering it out: a posture tool that exempts its own footprint is not measuring the account.
The dormancy lens shows the platform at its most careful — and the care is the product. Where activity data is not yet available, the assessment refuses to claim dormancy from silence and argues it from structure instead: empty membership, absent trust bindings, no inferable owner. It then labels its own confidence, per identity:
| Identity | Dormancy evidence | Reach if used |
|---|---|---|
| admin@… | Strong — no members, no owners | Minimal (read-only access approval) |
| capi-operator@… | Weak — no recorded trust, but a federation-shaped role set | Broad (full compute + cluster control) |
The second row is the one that matters. A service account holding a federation-admin role with no federation recorded is structurally anomalous — not provably dormant, and the assessment says so, but the first thing to check. That is the difference between a dormancy report you can act on and one you have to re-verify: an empty ownerless group is a housekeeping ticket; a possibly-unused account with full cluster control is an incident waiting for someone to find the key.
05 Insights
A finding feed that cites its evidence
Beyond the fixed rules and the graded assessments, the platform runs an automated insight pass — a layer that proposes findings on its own, mined from the tenant's change history: privilege drift between captures, activity bursts in the audit trail, dormant identities that suddenly act, sharing exposure that concentrates.
DesignEvery insight cites a record that exists
Each proposal must name its evidence — an identity, a principal, a capture — and every citation is resolved in code against the tenant's actual records before anything is stored. Severity thresholds, deduplication and evidence resolution all live on the platform side: the model decides what is worth saying; it never decides what the record says.
During the field study, that pass surfaced exactly the kind of catch the feed exists for.
HighTransient root-trusted escalation role, created and deleted inside 22 minutes
A role named svc-deploy-runner appeared in the production AWS account trusting the account's own root principal — which permits any principal in the account to assume it — carrying an inline policy explicitly named for privilege escalation. It was gone twenty-two minutes later, and does not appear in the current snapshot.
The pass reported it at high severity anyway, with the reasoning that a root-trusted, escalation-named role in a production account is a material security event regardless of intent, and that a deliberate demonstration still warrants explicit confirmation after the fact. It cited the role by name and the two captures that bracket its lifetime. All three citations resolve.
The evidence discipline is what makes a feed like this usable: a confident, well-written finding about a service account that does not exist would cost a security team more than it saves, so the platform makes that outcome structurally impossible. The claim is narrow, and worth exactly what it says: every published insight cites a record that exists, checked in code, against the tenant's own data, every time.
06 Change
A diff answers "what changed"; a sequence answers "what happened"
The finding above is only legible as a sequence. Here is the AWS environment's capture series over one working afternoon, with the identity count the platform recorded at each:
| Capture | Time (UTC) | Identities | Change |
|---|---|---|---|
| 1 | 17:32 | 29 | baseline |
| 3 | 18:00 | 29 | no change |
| 5 | 18:38 | 30 | svc-deploy-runner created |
| 7 | 19:00 | 29 | svc-deploy-runner deleted |
| 8 | 20:00 | 29 | no change |
Compare the newest pair of captures alone — 7 against 5 — and the honest report is a role was deleted. That is true, and it is useless: deletions are the shape of good hygiene, and a feed that pages someone about one is a feed they will turn off. Compare 5 against 3 alone and the report is a role was created, which is the ordinary business of a cloud account.
Only the sequence carries the finding. A role that exists for twenty-two minutes, trusts the account root, and is named for privilege escalation is a different claim from either of its halves — and it is the claim a reviewer would want, precisely because the evidence for it has already been cleaned up. The role was gone before anyone looked. The record of it was not.
So the platform computes the arithmetic rather than asking a model to: every consecutive pair of captures in the window is diffed in code, newest first, and the model is handed the whole sequence at once along with the standing privilege the change landed in. The judgement of which sequences matter is the model's. The question of what actually changed is never delegated.
This is also why the window is wider than the one diff a report strictly needs. Two captures answer "what changed last". Eight answer "what happened today", which is the question an operator asks — and it is the only way a change that was reverted before anyone noticed leaves a trace at all.
07 Behavior
From what it can do, to what it does
Everything so far reads the control plane: entitlements and their history. The platform's behavioral layer reads the other half — the audit streams both clouds emit continuously, already collected and normalized throughout the field study — and turns them into behavioral identifiers: named, versioned descriptions of how each principal actually acts over a window, each carrying a confidence and the exact events it was derived from. The evidence discipline of the insight feed, extended to behavior itself: no behavioral claim without the records behind it.
What that unlocks is the set of questions entitlements structurally cannot answer. Three of this paper's most careful sentences are the same sentence — dormancy argued from structure, reachability reported as unrecorded, audit collection contributing context but not findings — and each becomes a measurement:
| This paper said | The behavioral layer answers | Identifier |
|---|---|---|
| Dormancy argued from structure (§04) | Last observed action, or a measured silence | identity.dormancy |
| Reachability unrecorded (§03) | Who actually assumed the role, from where, on what cadence | identity.assumption_chain |
| 50% of principals hold privilege (§01) | The share that exercised it — the role that can do four thousand things and does six is a different risk from the role that uses everything it holds | scope.entitlement_utilization |
| Automation labelled by threshold | A composed classification with inspectable evidence (§08) | agent.signature |
The lifecycle-role door in §03 shows what that buys. Observed assumption chains settle the operational question theory cannot: those three roles were assumed a measured number of times, by a measured set of callers, from a measured set of instances, inside a measured time envelope. A single assumption outside that envelope is a finding with named evidence — and the possibly-dormant account in §04 resolves the same way: activity yields a finding with a service list; silence converts a structural guess into a measured dormancy.
08 Agents
An agent and a human can hold the same role. They never act the same.
The privilege network in the field study centred on one service-account role bound to 39 holders. Nothing in an entitlement inventory says how many of those holders are people — and AI agents operating with production credentials are precisely the population entitlement-based tools cannot address, because an agent and a human may hold identical entitlements.
Behavior separates them. Sub-second request cadence sustained over minutes. Tool-call-shaped sequences — list, describe, get, repeated. Retry loops with identical parameters. A flat hour-of-day profile. Each is its own measured signal, and together they compose into an automation signature — a classification with a confidence and inspectable evidence, not a guessed label.
The classification then changes the questions. An automated principal is judged against automated baselines: agents are expected to be narrow, so the first appearance of a new service in an agent's traffic means more, not less. A human producing thirty access-denied errors in a minute is misconfigured; an automated principal producing the same pattern is enumerating — and will continue. This is what identity security looks like when half the identities were never people.
09 Network
Every customer sharpens detection. No customer's data moves.
Recognition compounds. What burst patterns precede an incident, what dormancy profiles turn out to matter, which automation signatures are benign — every organization the platform watches makes those judgements sharper. IntegraTrace pools that learning as abstracted statistics per residency partition: patterns and priors cross organizations; records never do.
Residency is architecture here, not a checkbox. A tenant's data is captured, stored and processed in its own residency partition, and every layer described in this paper — capture, findings, assessments, the graph, the insight pass — operates inside that boundary. The network effect is real, and it is built out of the one thing that can safely cross a boundary: what the fleet has learned, never what any tenant has done.
10 Method
How these numbers were produced
Both environments were connected through the product's own onboarding flow using keyless federation — the platform assumes a read-only role in the customer's cloud with no stored credential of any kind, and holds no long-lived secret for either environment. It never writes to the accounts it reads.
| Layer | What ran | Output |
|---|---|---|
| Capture | Scheduled inventory of both environments | 76 identities |
| Rules | Deterministic checks, every capture | 17 findings |
| Assessment | 4 lenses × 2 environments | 8 assessments |
| Graph | Cross-environment identity index | 158 nodes / 173 edges |
| Audit | Native audit streams, continuous | both clouds |
| Insights | Automated passes over the change history | 1 published |
Pseudonymization. The environments are real and in daily use, so every human identifier, account number, project id and generated resource suffix in this report and its screenshots has been replaced with a synthetic stand-in. The substitution is consistent throughout and structure-preserving — an email is still an email, an account id is still twelve digits — so relationships between identities read exactly as they do in the product. Severities, counts, role names, policy names and assessment text are unmodified.
Counts are a moment, not a constant. Every figure here is the state at the time of the screenshots. The clearest example: open findings read 17 while the deliberately-created role above was present, and 16 once it was deleted and the next capture ran.
Limits worth stating. Dormancy in this study is argued from structure and labelled with its own confidence. Trust conditions a provider does not expose in inventory are reported as unrecorded rather than as absent — those are different claims and the distinction is preserved. One over-permissive role was created deliberately in the AWS account to exercise change detection, and removed once observed; it appears in this report as svc-deploy-runner.