Introducing Zorro Security / A new perspective on AI security ↗
zorroSECURITYSign in Build with us ↗

03 / IDENTITY & ACCESS

One inventory for people,
machines and agents.

A person, a service account and an AI agent are three kinds of principal and one kind of problem: authority that was granted once and never checked again. This module reads all three as the same row.

THE LOOP THIS PRODUCT HAS TO CLOSE

EDGE + GITHUB

ingest

The only live inbound paths. Ten connector kinds are registered and fail closed.

BUILT

graph

Entities, edges and provenance, projected from events that really happened.

BUILT, THIN INPUT

enrich

Classification and entitlement resolution over whatever the graph actually holds.

BUILT

analyze

Exposure scans, posture rules, path search, rollout simulation.

BUILT, NO BASELINE

profile

Per-entity reach and identity profiles. No behavioural or peer baseline.

ONE ACTION

remediate

Propose, approve, execute, verify. The only effector is revoking a session.

WHAT DOES NOT ARRIVE

There is no live identity-provider ingestion. Entra ID and Okta are registered connector kinds behind a fail-closed provider that reports NOT CONNECTED without a credential and UNAVAILABLE with one, so the accounts, roles and multi-factor attributes these rules read have to arrive from the edge or from GitHub. The four detectors below are written and they are small enough to audit. What they run over is thin, and that is the break. What is connected today ↗

WHAT CANNOT BE ACTED ON

No account can be disabled, no entitlement removed and no token killed from here, because each of those needs a connector that is not written. Acting on a right-sizing recommendation records that a person applied or dismissed it; it does not change an entitlement anywhere. The one thing the control plane can execute is revoking an agent session. The credential broker is the exception on this page, and the reason it is the exception is that it runs on the workstation and needs nothing connected.

One measured result lives on this page, and it is the one control here that depends on neither end of the loop: the credential broker runs on the workstation and needs no directory at all.

Three kinds of principal.
One profile shape.

People, machine identities and AI agents are each resolved into the same profile, because the question asked of them is the same one.

WHO IS IN IT

Everything that can hold a permission.

Person, machine identity and AI agent entities all become identity profiles. An agent that authenticates as a service account appears as itself and as the reach it inherits, rather than hiding inside the human it borrowed.

WHAT A PROFILE CARRIES

Accounts, role, activity, entitlements.

Accounts are attached from the graph's own neighbours. Role, status, days inactive, multi-factor enrolment and enforcement, and the entitlements resolved for that identity, each with what it targets.

WHERE IT COMES FROM

Attributes, never inference.

Every field is read from an attribute a source supplied or an edge the graph holds. An attribute nobody supplied stays unset. Nothing defaults to enrolled, to active or to safe.

Four findings,
four readable rules.

Each detector is a small rule over the profile, and each finding carries the evidence that produced it and the action it recommends to whoever will carry it out. There is no score to tune and no model in the path.

ZOMBIE ADMIN

Privilege without activity.

An administrative role, or an entitlement that grants one, held by an identity with ninety days of recorded inactivity. Critical, with the role, the days and the last login carried as evidence.

DORMANT ACCOUNT

Active on paper only.

Ninety days inactive while the directory still marks the account active, or thirty days for a contractor. High, because the account is not gone, it is only quiet.

MISSING MFA

Enrolled is not enforced.

Either flag missing raises the finding, and both are read from the source rather than assumed. Critical when the identity is administrative, high otherwise.

PRIVILEGE CREEP

Access across departments.

Two or more distinct group or department entitlements, or four or more entitlements in total. Medium, and the least urgent of the four, which is why it reads as a trim rather than an alarm.

A finding's identifier is derived from the tenant, the kind and the identity, so the same condition produces the same finding rather than a new one on every scan. A queue that grows because the scanner ran again is a queue nobody reads.

Compare what was granted
against what was used.

Over-privilege is not a policy violation. It is the gap between an entitlement someone was given and an entitlement someone exercised, and only one of those is visible in a directory.

GRANTED

Every entitlement, with its target.

Collected per identity from the graph: what the permission is, what it is on, and when it was given. This half is what an access review already shows you.

USED

When it was last exercised.

An entitlement that has gone unexercised is counted as dormant, with the number of days it has been unused carried on the recommendation. This half is the one that decides anything.

THE GAP

A recommendation, not an action.

The report names the entitlement to trim and the days behind that judgement. Acting on one is a separate call that either applies it or dismisses it, and the choice is recorded either way.

Two honest notes. The report computes a gap between dormant and total entitlements, and no figure from it appears on this site, because a percentage of a graph nobody has populated for you is a number about nothing. And applying a recommendation marks the recommendation applied. It does not reach into a directory and remove the entitlement, because there is no directory client to reach with.

The strongest identity control
is the secret that was never there.

An injected agent that dumps its environment finds nothing worth having, because the raw credential was never put in it. This is the one measured result on this page.

UNDER THE BROKER

0 of 9

leak vectors succeeded against a pinned list of collection techniques (demo_credential_broker.sh, macOS).

WITHOUT IT

6 of 8

leaked with the key in the agent's environment, which is how the affected workflows pass it today.

STILL WORKING

4 of 4

legitimate API calls forwarded with the key swapped in. A control that breaks the work is a control that gets removed.

ON LINUX

Untested

Measured on macOS only. The process-environment handling exists in code; no Linux run has been made, so no Linux result is claimed.

WHAT THE RUN CHECKED

  • The raw key never enters the agent environment
  • A loopback capability token stands in its place
  • The real key is swapped in at forward time
  • Forged and missing tokens are refused
  • The token is dead once the run ends
  • It refuses to start if the key is in its own environment
  • Or in an ancestor process command line
  • Where readable, an ancestor environment too

What it does not check, said plainly: the techniques are replayed by a script rather than produced by a hijacked model, the key is a random canary rather than a real credential, and reading the broker's own memory through a debugger was not attempted. The receipt records the host's tracing policy instead of claiming that path is closed.

Where the inventory
is still empty.

The detectors are written. What they detect over is a graph you have to feed.

Identity is one lens.
Here are the others.

The same entities, the same provenance, a different question on each page.

THE SECRET THAT WAS NEVER THERE

Take the credential out
of the environment.

It is the one control on this page with a measured result, and it needs nothing connected to try.

Talk about a pilot ↗