ADR-006: Entity Type Reclassification
Status
Accepted (2026-02-13)
Context
The original data model classified all automation artifacts (Business Rules, Script Includes, Flows, Scheduled Jobs, OAuth Profiles) as entity_type: "identity" with different identitySubtype values. This was pragmatically convenient during early development but semantically wrong:
- Script Includes don't authenticate — they are reusable code modules invoked by other automations, not principals that establish sessions
- OAuth Profiles are credentials, not identities — they hold client_id/client_secret pairs used by other entities to authenticate
- REST Messages are connection configurations — they define outbound HTTP endpoints, not authenticating entities
- NHI count inflated 13-18x by non-authenticating artifacts — a tenant with 5 real NHIs and 70 automation artifacts reports 75 "identities"
- 0 of 8 OAA community connectors classify automation artifacts as identities — every production connector in Veza's ecosystem treats automations as resources
Why this matters
SecurityV0's core value proposition is "show me your non-human identities and what they can do." If 93% of reported "identities" are actually automation logic, connection configs, and credentials, the platform loses credibility with CISOs who need accurate NHI inventory counts.
Decision
Split autonomous_identity into 4 distinct entity types based on what each artifact actually does:
| Entity Type | Definition | Examples |
|---|---|---|
identity | Entities that authenticate — they establish sessions, present credentials, appear in sign-in logs | Service Principal, OAuth App, Machine Account, Integration User |
automation | Entities that define execution logic — they run code but don't independently authenticate | Business Rule, Script Include, Flow, Scheduled Job |
connection | Outbound integration configurations — they define where data goes but don't authenticate or execute logic | REST Message, HTTP Connection |
credential | Authentication material — they hold secrets used by other entities to authenticate | OAuth Profile, API Key, Certificate |
Map human_identity to internal owner type via the platform normalizer. The NormalizedNodeType enum in the connector contract keeps human_identity — connectors are not responsible for this mapping; the platform handles it during ingestion.
Internal entity type inventory (9 types)
| Type | Source | Count Pattern |
|---|---|---|
identity | Connector (was autonomous_identity) | Low (5-20 per tenant) |
automation | Connector (was autonomous_identity) | High (50-200 per tenant) |
connection | Connector (was autonomous_identity) | Low (5-15 per tenant) |
credential | Connector (was autonomous_identity) | Low (5-15 per tenant) |
owner | Platform normalizer (from human_identity) | Medium (10-50 per tenant) |
role | Connector | Medium (10-100 per tenant) |
permission | Connector | High (50-500 per tenant) |
resource | Connector | High (50-500 per tenant) |
execution_evidence | Connector | High (varies with sign-in volume) |
Rationale
Classification criteria
Each artifact was evaluated on 3 axes:
- Does it authenticate? — Does it present credentials to establish a session?
- Does it execute logic? — Does it contain or trigger code execution?
- Does it hold secrets? — Does it store authentication material?
| Artifact | Authenticates | Executes | Holds Secrets | Correct Type |
|---|---|---|---|---|
| Service Principal | Yes | No | No | identity |
| OAuth App | Yes | No | No | identity |
| Business Rule | No | Yes | No | automation |
| Script Include | No | Yes | No | automation |
| Flow | No | Yes | No | automation |
| Scheduled Job | No | Yes | No | automation |
| REST Message | No | No | No | connection |
| OAuth Profile | No | No | Yes | credential |
OAA alignment
All 8 surveyed OAA community connectors classify automation artifacts as resources, not identities. This decision aligns SecurityV0 with established practice while preserving our richer internal model.
Consequences
Positive
- NHI count accurately reflects authenticating entities only — CISOs get a real count, not an inflated number
- Clean governance categories — govern identities, monitor automations, rotate credentials, audit connections
- OAA export becomes natural — identities map to
local_user, automations toresource(see ADR-009) - Type-safe graph traversal — edge constraints can enforce valid from/to type pairs (see ADR-007)
Negative
- All code that assumes
identity = automation artifactmust be updated — 13 known locations across platform and connector codebases - Migration window required — platform must accept both old (
autonomous_identitywith subtypes) and new (4 distinct types) during transition - Connector contract preserved but expanded — connectors still emit
human_identity; platform handles mapping. NewNormalizedNodeTypevalues added forautomation,connection,credential
Neutral
- Connector interface change is additive — existing connectors continue to work during migration window; new type values are opt-in until migration completes
When to Reconsider
- If a new source system has artifacts that don't fit cleanly into the 4-type split (e.g., an entity that both authenticates and executes logic)
- If the OAA community adopts a different convention for automation classification
Analysis
Round 5 Synthesis — 6 agents, 7,844 lines, 5/6 majority