AI-native security for machine identities
Automation holds the keys.
Ordrani watches how it uses them.
Ordrani Security delivers AI-native threat detection for non-human identities and automated cloud workflows. Its models learn how each service account, cloud role and CI/CD pipeline is expected to operate, and produce traceable evidence when an authorized identity begins acting outside its purpose.
ordrani / workflows / payments-service · deploy.yml
LIVEExecution lineage
Attributed activity
prod-deploy-role
- 14:32:05workflow_run · deploy.ymlrun 4182
- 14:32:05sts:AssumeRoleWithWebIdentityOIDC · confirmed
- 14:32:09ecr:BatchGetImagewithin purpose
- 14:32:41ecs:UpdateServicewithin purpose
- 14:33:40iam:ListRoles ×37novel for identity
- 14:36:12secretsmanager:GetSecretValuesensitive
- 14:41:50iam:PutRolePolicyprivilege change
Case OR-0142 opened
HIGHPotential workflow identity misuse
enumeration → secret access → policy change · attribution confirmed
AI built for non-human identities
Models designed around how service accounts, cloud roles and pipelines behave — not user analytics adapted to machines.
Evidence, not alert volume
Findings arrive as connected investigations with stated confidence, rather than isolated anomaly scores.
Observation first, authority retained
Integrations are read-only. Any response that changes your environment remains a human decision.
Perspective
Security has spent two decades learning how people behave. The systems now running infrastructure are not people. Ordrani is built to understand them on their own terms.
01The shift
Most activity in a modern cloud environment is no longer initiated by a person.
Deployment pipelines assume cloud roles and push changes to production. Backend services query databases and call internal APIs. Scheduled jobs rotate keys, move data and reconfigure infrastructure. None of this waits for someone to sign in.
Each of these systems acts through a non-human identity — a role, token, key or service account that grants it standing access. These identities now outnumber the people in most engineering organizations. They operate continuously, they are rarely reviewed, and many hold more privilege than any individual engineer.
The operational surface of the enterprise has become machine-driven. Its security model has not fully caught up.
01
CI/CD pipelines
02
Service accounts
03
Workload identities
04
API and OAuth integrations
05
AI agents
02The visibility gap
Authorized is not the same as expected.
When a machine credential is compromised, the attacker inherits its legitimacy. Every request is authenticated. Every permission check passes. To the logging system, the activity looks like automation doing its job.
Identity governance asks
Which permissions does this identity hold?
Essential for reducing standing privilege — but a role used maliciously within its permissions is invisible to an entitlement review.
Cloud threat detection asks
Is this API call known-bad or statistically rare?
Effective against recognizable attack patterns, but it seldom knows which pipeline or job produced the activity, or what that automation exists to do.
The missing question
Is this consistent with the purpose of the automation that produced it?
Answering it requires knowing the workflow behind each operation, what that workflow is meant to do, and how its identity normally behaves. That is the problem Ordrani is built around.
Ordrani complements identity governance, cloud-native detection and your SIEM — it does not replace them. It contributes the layer of context they were not built to hold.
03AI at the core
Specialized AI models, one line of reasoning.
Ordrani is AI-native. Instead of one general model guessing at what looks suspicious, it is built around specialized models that each answer one question about machine activity — how an identity behaves, which workflow is responsible, whether events form an attack, and what the evidence means.
Each judgement is made against two references at once: how an identity has historically behaved, and what the workflow behind it is authorized to do. Where they disagree, the platform looks for corroborating evidence before it raises a case.
01Behavior models
Machine learningWhat does this identity normally access, modify and execute?
Models learn a baseline for every machine identity — timing, API usage, resource scope, permission use and companion identities — and re-learn after approved change instead of flagging it indefinitely.
02Provenance inference
Probabilistic attributionWhich repository, workflow and execution produced this operation?
Links cloud sessions to the pipeline runs that created them from federated identity claims, session metadata and deployment context, and scores how certain each link is.
03Sequence and graph models
Temporal graph AIDo these connected operations form an attack progression?
Reason over ordered events across systems to recognize progressions such as enumeration, then privilege change, then sensitive access — weighing the evidence rather than reacting to one signal.
04Investigation model
Language modelWhat happened, how sure are we, and what should happen next?
An evidence-grounded language model writes each case in plain language, cites the source event behind every statement, states what is unconfirmed and leaves every decision to a person.
04Platform capabilities
One intelligence layer across identities, workflows and cloud activity.
05Identity and workflow intelligence
Every cloud operation, traced to the execution that produced it.
A role session in AWS does not, by itself, say which pipeline run created it. Ordrani reconstructs that lineage — from repository and workflow, through federated token exchange, to the session and every operation it performed.
01
Repository
org/payments-service
workflow file
02
Workflow
deploy.yml · production
run id
03
Execution
run 4182 · job deploy
OIDC claims
04
Federated token
sub · job_workflow_ref
AssumeRoleWithWebIdentity
05
Role session
prod-deploy-role
session ARN
06
Operations
API calls and resources
Attribution is evidence. Ordrani states how strong it is.
Not every operation can be bound to a specific job with certainty. Rather than presenting inference as fact, each relationship carries an explicit confidence level that analysts can see and challenge.
Confirmed attribution
The link is established by verifiable identifiers — OIDC claims bound to a role session, a session ARN recorded on each API call. Ordrani treats these as fact.
Strong correlation
The link is supported by multiple independent signals such as role, timing, source network and resource overlap, but no single identifier proves it.
Unverified hypothesis
A plausible explanation the evidence does not yet support. Shown to analysts as a question to resolve, never as a conclusion.
06Detection and investigation
From scattered events to one explainable case.
A role enumeration in AWS, a secret read four minutes later, a policy change on an unrelated role. Viewed separately, each is a low-priority anomaly. Connected through a shared identity and timeline, they describe an intrusion.
- A reconstructed sequence, ordered by event time across systems
- The identity, workflow and execution responsible — with attribution confidence
- The assets affected and why they matter
- An assessment written from the evidence, including what remains unconfirmed
- Recommended next steps, with any change to your environment held for approval
CASE OR-0142 · OPENED 14:42 UTC
Potential workflow identity misuse
Identity prod-deploy-role · origin deploy.yml #4182
Reconstructed sequence
- 14:32:05
sts:AssumeRoleWithWebIdentity
org/payments-service · environment: production
Confirmed - 14:32:41
ecs:UpdateService
payments-api · task definition rev 212
Confirmed - 14:33:40
iam:ListRoles, iam:ListPolicies
37 calls in 52 s · first observed for this identity
EnumerationConfirmed - 14:36:12
secretsmanager:GetSecretValue
prod/db-credentials · classified sensitive
Sensitive accessCorrelated - 14:41:50
iam:PutRolePolicy
inline policy added to reporting-export-role
Privilege changeCorrelated
Assessment
A deployment identity performed role enumeration it has never performed, then a sensitive secret was read by the same role after the run completed. The sequence is consistent with credential or workflow misuse. Authorization of the run has not been confirmed.
Affected assets
- prod/db-credentials
- reporting-export-role
- payments-api (ECS)
Recommended next steps
- 1.Confirm with the repository owner whether run 4182 was an authorized deployment.
- 2.Review active sessions for prod-deploy-role and their source networks.
- 3.Inspect the inline policy added to reporting-export-role.
- 4.Revoke sessions and restrict the role trust policy — requires approval.
07Enterprise applications
Where machine identity threats surface.
Ordrani is built for organizations whose infrastructure is operated through automation — cloud-native software companies, financial technology providers and the security teams responsible for them.
Compromised service accounts
Credentials used from new contexts, at new times, against new resources.
Unusual cloud role activity
Roles exercising permissions they hold but have never needed.
Deployment workflow misuse
Pipelines running from unexpected branches or reaching beyond their scope.
Suspicious machine-to-machine access
Services forming relationships with systems they have no reason to reach.
Unexpected sensitive-resource access
Automation reading secrets, keys or data stores outside its function.
Cross-system privilege misuse
Privilege gained in one system and exercised in another.
A continuous behavioral intelligence layer for machine-driven enterprises.
Ordrani secures GitHub-driven automation operating in AWS end to end, and the same model is extending to Kubernetes, additional clouds and the AI agents now acting on behalf of engineering teams.