OAA Mapping Analysis — CISO

Role: CISO, SecurityV0 Automation-Analysis Team (Round 4) Date: 2026-02-13 Classification: Internal — Security and Compliance Advisory Scope: Whether modeling automations as OAA Applications, OAA Resources, or the Round 3 execution_chains approach best serves compliance attestation, forensic investigation, and audit readiness. Evaluates the founder's insight that automation chains resemble OAA Applications rather than Identities, and that trigger events and data modifications resemble OAA Resources.

Executive Summary

The founder's observation is architecturally significant: autonomous execution chains are not identities — they are composite execution environments with users, roles, permissions, and resources. This maps more naturally to OAA's Application concept than to its Local User concept. A Business Rule that fires on an incident table insert, calls a Script Include, invokes a REST message to Microsoft Graph, and authenticates via an OAuth client through a Service Principal is not a "user" of ServiceNow — it is a self-contained application that consumes data, processes it through logic, and produces output in another system.

However, this insight does not invalidate the Round 3 execution_chains recommendation. It enriches it. The OAA Application model provides a standardized vocabulary for describing what an automation chain does (permissions on resources), while the execution_chains collection provides the temporal, compositional, and forensic capabilities that OAA lacks entirely.

Bottom line: SecurityV0 should model each automation chain as both:

An execution_chains document (Round 3) — providing stable identity, temporal versioning, composition tracking, and chain-level findings
An OAA Application export — providing standardized permission/resource vocabulary for compliance attestation and cross-system queries

These are not competing approaches. The execution_chains collection is the internal representation; the OAA Application is the external attestation format. The chain is the persistence layer; the Application is the compliance layer.

This analysis walks through each of the six questions posed, with compliance matrices, forensic scenario walkthroughs, and risk assessments that demonstrate why this dual approach is both necessary and sufficient.

1. Security Implications of "Automation as Application"

1.1 What Changes in the OAA Application Model

Under OAA, an Application is a top-level container that groups:

Local Users — identities within the application
Local Groups — groupings of users
Local Roles — named bundles of permissions
Permissions — canonical CRUD actions (10 types)
Resources — data and system components (nestable)
Identity-to-Permission Bindings — who has what on what

If we model the AzureGraphRouter automation chain as an OAA Application, the mapping becomes:

OAA Application: "AzureGraphRouter — Incident Routing"
  application_type: "automation_chain"

  local_users:
    - Business Rule: "Auto-route identity tickets"     (role: trigger)
    - Script Include: "AzureGraphRouter"                (role: executor)
    - Service Principal: "sn-ticket-router"             (role: destination_identity)

  permissions:
    - DataRead on incident_table                        (canonical: DataRead)
    - DataWrite on incident_table (assignment_group)    (canonical: DataWrite)
    - DataRead on entra_users (department lookup)       (canonical: DataRead)
    - NonData: execute REST message to graph.microsoft.com  (canonical: NonData)

  resources:
    - incident_table (sensitivity: internal, domain: it_ops)
    - entra_users (sensitivity: confidential, domain: identity_platform)
    - graph.microsoft.com (sensitivity: confidential, domain: identity_platform)

  identity_to_permissions:
    - BR "Auto-route" → DataRead on incident_table (trigger reads incidents)
    - SI "AzureGraphRouter" → NonData on graph.microsoft.com (executes REST call)
    - SP "sn-ticket-router" → DataRead on entra_users (queries Graph API)
    - SP "sn-ticket-router" → DataWrite on incident_table (writes assignment_group)

1.2 How This Changes the Compliance Mapping from Round 3

Round 3 identified five compliance control gaps. Here is how the "Automation as Application" model affects each:

Control	Round 3 Gap	OAA Application Impact	Net Assessment
CC6.1 (Access Controls)	Cannot show chain access at time T	Application model groups all permissions in one container — CISO can enumerate "Application permissions" at current state. But OAA is snapshot-based — no temporal versioning of Application state.	IMPROVED for current state, UNCHANGED for temporal. The Application container makes current-state attestation cleaner. But OAA has no concept of "what did this Application look like 90 days ago." Still need `execution_chains` versioning.
CC7.1 (Monitoring)	Chain-level expansion undetectable	Application model enables permission-level monitoring — "Application gained new DataWrite." But OAA has no monitoring or alerting mechanism. Detection logic must be external.	IMPROVED for detection vocabulary, UNCHANGED for detection mechanism. OAA gives us the canonical permission language (DataWrite vs DataRead). The evaluator still must implement chain-level comparison.
CC8.1 (Change Management)	Chain composition changes not tracked	Application model captures current composition but has no change history. OAA snapshots are replacements, not diffs.	UNCHANGED. OAA does not track changes. The `execution_chains` versioning is still required.
ISO A.5.9 (Asset Lifecycle)	Chains not identifiable as assets	Application model gives each automation a name, type, and enumerable contents — directly satisfying asset identity requirements.	SIGNIFICANTLY IMPROVED. This is where OAA adds the most value. An "Application" is an industry-recognized concept that auditors understand.
SOX ITGC	Cannot reconstruct chain access at past dates	OAA snapshots are current-state only. No temporal capability.	UNCHANGED. OAA provides no historical capability.

Summary: OAA Application modeling improves current-state attestation and asset identity (the two areas where OAA is designed to work). It does not improve temporal queries, change tracking, or monitoring (the three areas where SecurityV0's execution_chains with versioning is required).

1.3 Impact on the Incident Response Scenario (Day 0-91 Breach)

Revisiting the scenario from Round 3:

Day 0: AzureGraphRouter chain runs normally
Day 30: Someone adds hr_admin role to SP sn-ticket-router
Day 60: Chain now reads HR cases (PII)
Day 90: Data breach discovered
Day 91: CISO opens SecurityV0

With "Automation as Application" modeling:

Question	Without OAA Application	With OAA Application	Improvement
"Show me all automations that have DataWrite on HR data"	Must scan all entities, filter by automation subtypes, traverse to permissions, check resource classification	Query: `GET /execution-chains?permission=DataWrite&resource_domain=hr` using OAA canonical vocabulary	Major improvement. The canonical permission vocabulary makes this query expressible.
"When did this Application gain DataWrite on HR data?"	Not answerable from OAA alone (snapshot-based)	Not answerable from OAA alone. Requires chain versioning.	No improvement. OAA adds the vocabulary but not the temporal capability.
"What is this Application's current blast radius?"	Must traverse entity graph	Application's `resources` list with sensitivity classification	Moderate improvement. The Application container pre-groups resources.
"Was this Application actively executing?"	Query execution_evidence for component entities	Same — OAA has no execution evidence concept	No improvement. OAA does not model execution.

Net assessment for incident response: The OAA Application model improves the query vocabulary — the CISO can ask questions using standardized terms (DataWrite, DataRead, Resource sensitivity). But it does not improve the temporal investigation — the ability to trace what happened when, which requires execution_chains versioning.

1.4 Can the CISO Query "All Applications of Type Automation That Have DataWrite on HR Data"?

Yes — and this is the single most compelling argument for the OAA Application model.

The query becomes:

db.execution_chains.find({
  "oaa_export.permissions": {
    $elemMatch: {
      canonical_type: "DataWrite",
      resource_domain: "hr"
    }
  }
})

Or via the API:

GET /api/v1/execution-chains?canonical_permission=DataWrite&resource_domain=hr

This query is not possible today because:

There is no chain-level container to search
Permissions are not canonically typed at the chain level
Resource domains are not aggregated at the chain level

The OAA Application model — applied to execution_chains as an export/attestation layer — makes this query natural and fast.

2. The Data/Resource Perspective

2.1 OAA's View: Application with DataRead and DataWrite

When an automation reads from the incident table and writes to Entra, OAA would model this as:

Application: "AzureGraphRouter"
  has permission DataRead on Resource "incident_table"
  has permission DataWrite on Resource "entra_users"
  has permission NonData on Resource "graph.microsoft.com" (the REST call)

This is a clean, auditable statement. An auditor can read it and understand: this automation reads IT tickets and modifies identity data.

2.2 What Is Sufficient, and What Is Missing

What OAA captures well:

Aspect	OAA Coverage	Assessment
What data the automation reads	DataRead on specific resources	Sufficient
What data the automation writes	DataWrite on specific resources	Sufficient
What system actions it performs	NonData for execution actions	Partial (see Section 6)
What resources are involved	Resource hierarchy with sensitivity	Good
Cross-system data flow	Resources from multiple systems	Good

What OAA misses entirely:

Gap	Why It Matters for Forensics	Severity
No execution evidence	OAA says the automation CAN read incident data. It does not say the automation DID read incident data, how many times, or when. For forensic investigation, the difference between "can" and "did" is the difference between theoretical exposure and actual breach.	Critical
No temporal state	OAA captures the current permission set. It does not capture when each permission was granted, by whom, or how the set changed over time. For the Day 30 scenario (SP gains hr_admin), OAA shows the current state but not the transition.	Critical
No execution path	OAA shows identity-to-permission bindings but not the traversal path. The AzureGraphRouter chain flows BR → SI → REST → OAuth → SP. OAA flattens this into "Application has permission X on resource Y." The chain topology — which component does what — is lost.	High
No ownership	OAA has no concept of who is accountable for this Application. The entire ownership decay model — primary owner departed, secondary team disbanded — is invisible.	Critical
No credential lifecycle	OAA does not model the OAuth client secret, its rotation status, its expiry date, or whether it was recently compromised.	High
No trigger mechanism	OAA does not model HOW the automation fires. "Triggered by incident table insert" vs "triggered by scheduled job at 3 AM" has materially different risk profiles.	Medium

2.3 The Privilege Escalation Path Question

"How does 'who gave this automation DataWrite on HR data' map to the actual privilege escalation path?"

This is where OAA's abstraction becomes dangerous for forensics.

OAA says: "Application AzureGraphRouter has DataWrite on entra_users."

The actual privilege chain is:

bob.chen@corp.com added role hr_admin to SP sn-ticket-router on Day 30
hr_admin role GRANTS permission hr_case.write (canonical: DataWrite)
hr_case.write APPLIES_TO resource hr_case (domain: hr, sensitivity: confidential)
SP sn-ticket-router is in the AzureGraphRouter chain via RUNS_AS from SI
Therefore the AzureGraphRouter chain gained DataWrite on HR data

OAA captures step 2 (permission canonical type), step 3 (resource), and the final conclusion (Application has DataWrite on HR data). It loses:

Step 1: Who made the change and when (actor attribution, temporal)
Step 4: How the chain inherits the permission (composition, RUNS_AS traversal)
Step 5: The causal chain from role addition to Application-level impact

For forensic investigation, the CISO needs all five steps. The OAA Application model gives a useful summary (step 2-3 and conclusion), but the investigation requires the full path (steps 1-5), which only the execution_chains + entity versioning can provide.

2.4 Incident Table as Resource, Entra Users as Resource

The founder's insight that trigger events and data modifications look like "data" or "resource" is correct in OAA terms:

Element	OAA Modeling	Properties
Incident table (trigger source)	Resource	type: table, domain: it_ops, sensitivity: internal
Incident table (write-back target)	Resource	Same resource, different permission (DataRead vs DataWrite)
Entra users (lookup target)	Resource	type: api_endpoint, domain: identity_platform, sensitivity: confidential
HR case table (expanded access)	Resource	type: table, domain: hr, sensitivity: confidential, contains_pii: true

This modeling is sound. The incident table is simultaneously a trigger source (the automation fires when a record is inserted) and a write target (the automation updates assignment_group). OAA captures both via separate permissions on the same resource.

What OAA does not capture is the directionality of data flow:

incident_table → [trigger] → AzureGraphRouter → [query] → entra_users → [write] → incident_table

The automation reads from the incident table, queries Entra, and writes back to the incident table. This is a data flow loop. OAA captures "DataRead on incident_table" and "DataWrite on incident_table" but not the fact that these are temporally ordered steps in a single execution flow. For forensics, knowing the order matters — the write depends on the read, and data from the read (incident details) flows through external systems (Entra) before being written back.

3. Compliance Impact of OAA Alignment

3.1 SOC2 CC6.1 — Logical and Physical Access Controls

Requirement: Implement logical access security measures to protect against unauthorized access to information assets.

Approach	Current State	After Phase 1 (execution_chains)	After Phase 1 + OAA Application
Asset identification	Entities identified; chains not	Chains identified with stable IDs	Chains identified as named Applications with typed permissions
Permission enumeration	Entity-level roles queryable	Chain aggregate blast radius	Chain permissions in canonical OAA vocabulary — auditor sees "DataWrite on hr_case" not "hr_agent_workspace role with incident.write ACL"
Cross-system access	AUTHENTICATES_TO edges on entities	Chain summary includes cross-system targets	Application resources span systems — single view of all accessed data
Point-in-time access	Entity versions (expensive reconstruction)	Chain versions (direct lookup after Phase 2)	OAA adds nothing — snapshot-based, no temporal

Verdict: OAA improves CC6.1 attestation for current state. The canonical permission vocabulary makes it dramatically easier to communicate access scope to auditors. "This automation has DataRead and DataWrite on HR data with NonData execution on the Microsoft Graph API" is an auditor-ready statement. "This automation's service principal holds hr_agent_workspace, itil, personalize, and task_editor roles in ServiceNow" requires the auditor to understand ServiceNow's role model.

OAA does not help with CC6.1 temporal attestation. Still requires execution_chains versioning (Phase 2).

3.2 SOC2 CC7.1 — System Monitoring

Requirement: Use monitoring activities to detect anomalies that could indicate compromise, service disruptions, or other issues.

Approach	Detection Capability	Gap
Entity-level only	scope_drift fires when SP gains roles	Misses chain-level expansion via permission/resource changes
execution_chains (Round 3)	Chain composition hash detects structural changes; chain blast radius detects access expansion	Detects what changed but not in standardized vocabulary
execution_chains + OAA canonical	Chain permission set change detected in canonical terms: "Application gained DataWrite on hr_case (confidential)"	Standardized finding language maps to compliance vocabulary

Verdict: OAA significantly improves CC7.1 finding quality. The finding "chain_blast_radius_expanded: DataWrite on confidential HR resource" is immediately actionable and maps to CC7.1 without translation. The finding "chain_blast_radius_expanded: hr_agent_workspace role added" requires the auditor to look up what hr_agent_workspace grants.

Concrete improvement:

WITHOUT OAA CANONICAL:
Finding: chain_blast_radius_expanded
  Chain: AzureGraphRouter
  Change: SP sn-ticket-router gained role hr_agent_workspace
  New resources: hr_case, sys_user

WITH OAA CANONICAL:
Finding: chain_blast_radius_expanded
  Application: AzureGraphRouter
  Change: Application gained DataWrite on hr_case (confidential, contains_pii)
  Canonical impact: +DataWrite on hr domain, +DataRead on identity_platform domain
  Sensitivity escalation: internal → confidential

The second version is audit-ready. The first requires interpretation.

3.3 SOC2 CC8.1 — Change Management

Requirement: Authorize, design, develop, configure, document, test, approve, and implement changes to infrastructure and software.

Approach	Change Tracking	Auditor Query
Entity-level events	"bob.chen@corp.com added hr_admin to SP"	Auditor must trace from SP to chain to understand impact
execution_chains versioning	"Chain composition changed: blast radius expanded"	Auditor sees chain-level change but not in canonical terms
execution_chains + OAA	"Application AzureGraphRouter gained DataWrite on hr_case (confidential). Cause: hr_admin role added to SP sn-ticket-router by bob.chen@corp.com on 2026-01-30"	Auditor sees: who, what, when, and impact in canonical terms

Verdict: OAA improves CC8.1 by providing standardized impact vocabulary. The change event connects the actor (bob.chen), the action (role addition), the entity (SP), and the canonical impact (DataWrite on confidential resource) in a single auditable record. Without OAA canonical types, the auditor must manually classify the impact of the role change.

3.4 ISO 27001 A.5.9 — Inventory of Information and Associated Assets

Requirement: Maintain an inventory of information processing assets with identification, classification, ownership, and periodic review.

Criterion	Entity-Level	execution_chains	OAA Application
Identification	Entities have IDs	Chains have stable IDs	Applications have names, types, and IDs — industry-standard
Classification	Entity sensitivity per-resource	Chain aggregate sensitivity	Application-level sensitivity derived from resource classification
Ownership	OWNED_BY on entities	Chain aggregate ownership	OAA has no ownership concept — must extend
Periodic review	Entity-level review	Chain-level review workflow	Application review workflow aligns with existing GRC tooling

Verdict: OAA Application is the strongest model for A.5.9 compliance.

Auditors already understand "Applications" as entries in an asset inventory. GRC tools (ServiceNow GRC, Archer, OneTrust) have "Application" as a first-class asset type. If SecurityV0 can export automation chains as OAA Applications, the chain appears in the organization's existing asset inventory without custom mapping.

This is the most practical compliance benefit of the OAA Application model: it speaks the auditor's language.

3.5 SOX ITGC — IT General Controls

Requirement: Access to financial reporting systems must be controlled, documented, and auditable at any past date.

Approach	Can reconstruct access at past date?	Audit trail complete?
Entity-level	Expensive multi-entity reconstruction	Events on individual entities
execution_chains (Round 3 Phase 2)	Direct lookup via chain versions	Chain-level events with composition diff
OAA Application	No — snapshot-based, no temporal	No — no change tracking

Verdict: OAA adds nothing for SOX ITGC temporal requirements. SOX ITGC demands historical reconstruction. OAA is current-state only. The execution_chains versioning from Round 3 Phase 2 remains the only approach that satisfies SOX ITGC.

However: If the automation chain's OAA Application export is included in each chain version, the historical state is expressed in canonical terms:

// execution_chain_versions document
{
  chain_id: "chain-azuregraphrouter-001",
  valid_at: ISODate("2026-01-30"),

  // Round 3 composition
  member_entities: [...],
  aggregate_blast_radius: {...},

  // OAA Application snapshot at this point in time
  oaa_snapshot: {
    permissions: [
      { canonical_type: "DataRead", resource: "incident_table", domain: "it_ops", sensitivity: "internal" },
      { canonical_type: "DataWrite", resource: "incident_table", domain: "it_ops", sensitivity: "internal" },
      { canonical_type: "DataRead", resource: "entra_users", domain: "identity_platform", sensitivity: "confidential" }
    ],
    resources: [...],
    max_sensitivity: "confidential"
  }
}

This means the SOX auditor can query: "At date X, what canonical permissions did this Application have, and on which resources?" The answer is a direct lookup.

3.6 Compliance Summary Matrix

Control	Entity-Only	execution_chains (R3)	OAA Application Only	execution_chains + OAA
CC6.1 (Access)	PARTIAL	PARTIAL (Phase 1) / MET (Phase 2)	IMPROVED current state, NO temporal	MET — canonical vocabulary + temporal
CC7.1 (Monitor)	PARTIAL	IMPROVED	IMPROVED vocabulary	MET — standardized findings
CC8.1 (Change)	CANNOT ATTEST	PARTIAL (Phase 1) / MET (Phase 2)	NO change tracking	MET — canonical impact vocabulary + chain events
A.5.9 (Asset)	NOT MET	MET	STRONGLY MET — industry-standard asset type	STRONGLY MET
SOX ITGC	HIGH RISK	PARTIAL (Phase 1) / MET (Phase 2)	NOT MET — no temporal	MET — canonical snapshots in versions

The clear winner is the combined approach: execution_chains + OAA canonical vocabulary.

Neither approach alone is sufficient:

execution_chains without OAA: functional but speaks an internal vocabulary that auditors must learn
OAA without execution_chains: clean vocabulary but no temporal capability, no change tracking, no execution evidence

Together, they provide audit-ready output (OAA canonical language) with audit-complete capability (temporal versions, change events, forensic investigation).

4. Forensic Query Capability: Day 0-91 Breach Scenario

4.1 Setup (Identical to Round 3)

Day 0: AzureGraphRouter chain runs normally — reads incidents, queries Microsoft Graph for user department, writes assignment_group back to incident
Day 30: Someone adds hr_admin role to SP sn-ticket-router
Day 60: Chain now reads HR cases (PII) via expanded role
Day 90: Data breach discovered — HR data exfiltrated
Day 91: CISO opens SecurityV0

4.2 Approach A: "Automation as Application" (OAA-Only)

Day 91, CISO queries:

Q1: "What automations have DataWrite on HR data?"

GET /api/v1/oaa/applications?permission_type=DataWrite&resource_domain=hr

Result: Application "AzureGraphRouter" — DataWrite on hr_case (confidential, PII)

Time to answer: ~2 seconds (direct index query on canonical permission type + resource domain)

Q2: "When did this Application gain DataWrite on HR data?"

OAA has no temporal capability. The current snapshot shows the permission exists. The CISO cannot determine when it was added.

Time to answer: UNANSWERABLE with OAA alone.

Q3: "Who gave this Application DataWrite on HR data?"

OAA does not track actor attribution on permission changes. No change history.

Time to answer: UNANSWERABLE with OAA alone.

Q4: "What data was this Application accessing before Day 30?"

OAA is snapshot-based. There is no previous snapshot to compare.

Time to answer: UNANSWERABLE with OAA alone.

Q5: "Was this Application actively executing during the exposure window?"

OAA does not model execution evidence. No sign-in logs, no API call records, no flow execution contexts.

Time to answer: UNANSWERABLE with OAA alone.

Assessment: OAA Application model answers Q1 (the discovery query) excellently. It fails completely on Q2-Q5 (the investigation queries). This is consistent with OAA's design — it is an authorization catalog, not a forensic tool.

4.3 Approach B: "Automation as Resource" (OAA-Only)

Under this approach, the automation itself is modeled as a Resource, and the identities within it (BR, SI, SP) are modeled as Local Users with permissions on that Resource.

Application: "ServiceNow Production"
  resources:
    - "AzureGraphRouter automation" (type: automation, sensitivity: confidential)
      sub_resources:
        - incident_table (type: table)
        - entra_users (type: api_endpoint)

  local_users:
    - SP sn-ticket-router

  identity_to_permissions:
    - SP sn-ticket-router → DataRead on "AzureGraphRouter automation"
    - SP sn-ticket-router → DataWrite on "AzureGraphRouter automation"
    - SP sn-ticket-router → NonData on "AzureGraphRouter automation"

Problems with this approach:

Problem	Impact
Automation is not "data"	The AzureGraphRouter chain is not something that identities access — it IS the thing that accesses. Modeling it as a Resource inverts the relationship.
Loses chain composition	The BR, SI, REST message, and OAuth client are all part of the chain. Modeling the chain as a Resource loses the internal structure — you can see the SP has access to the "automation resource" but not how the automation is composed.
Confuses permission direction	"SP has DataWrite on automation" means the SP can modify the automation. But the actual relationship is the SP executes AS the automation's terminal identity. The permission direction is wrong.
Makes cross-system flow invisible	The chain spans ServiceNow → Microsoft Graph → ServiceNow. Modeling it as a Resource in ServiceNow loses the cross-system traversal.

Day 91 forensic queries under Resource model:

Q1: "What resources have DataWrite on HR data?" — Must traverse sub-resources, which flattens the topology
Q2-Q5: Same as Approach A — OAA has no temporal, attribution, or execution evidence

Assessment: The Resource approach is semantically incorrect for automations. An automation is an actor, not a target. Modeling it as a Resource produces confusing permission relationships and loses the chain's internal structure and cross-system flow.

4.4 Approach C: Round 3 `execution_chains` (Without OAA)

Day 91, CISO queries:

Q1: "What automations have access to HR data?"

GET /api/v1/execution-chains?blast_radius_domain=hr

Result: Chain "AzureGraphRouter" — blast radius includes hr_case (confidential)

Time to answer: ~2 seconds (direct query on aggregate blast_radius)

Note: Without OAA canonical types, the query is by resource domain, not by permission type. The CISO cannot easily distinguish "automations that READ HR data" from "automations that WRITE HR data" without examining individual entity permissions.

Q2: "When did this chain gain access to HR data?"

GET /api/v1/execution-chains/chain-azuregraphrouter-001/versions?blast_radius_changed=true

Result: Version N (2026-01-30) — blast_radius_added: hr_case (confidential). Cause: hr_admin role added to SP sn-ticket-router.

Time to answer: ~3 seconds (chain version diff lookup)

Q3: "Who granted the access expansion?"

GET /api/v1/events?chain_id=chain-azuregraphrouter-001&event_type=chain_blast_radius_changed

Result: Event at 2026-01-30, actor: bob.chen@corp.com, change: hr_admin role added to SP sn-ticket-router.

Time to answer: ~3 seconds (chain event with actor attribution)

Q4: "What was the chain's access before Day 30?"

GET /api/v1/execution-chains/chain-azuregraphrouter-001/versions?valid_at=2026-01-29

Result: Version N-1 — blast_radius: [incident_table (internal), entra_users (confidential)]. No HR resources.

Time to answer: ~2 seconds (point-in-time version lookup)

Q5: "Was the chain executing during the exposure window?"

GET /api/v1/execution-evidence?entity_id=uuid-sp-sn-ticket-router&after=2026-01-30&before=2026-03-30

Result: 847 execution events during the 60-day window.

Time to answer: ~3 seconds (execution evidence query on chain component)

Assessment: Round 3 execution_chains answers all five questions. Q1 is slightly less precise than the OAA approach (blast radius domain vs canonical permission type), but Q2-Q5 are only answerable with chain versioning.

4.5 Approach D: `execution_chains` + OAA Canonical Vocabulary (Recommended)

Day 91, CISO queries:

Q1: "What automations have DataWrite on HR data?"

GET /api/v1/execution-chains?canonical_permission=DataWrite&resource_domain=hr

Result: Application "AzureGraphRouter" — DataWrite on hr_case (confidential, PII)

Time to answer: ~2 seconds (canonical permission + resource domain index query)

Q2: "When did this Application gain DataWrite on HR data?"

GET /api/v1/execution-chains/chain-azuregraphrouter-001/versions?permission_changed=true

Result: Version N (2026-01-30) — Permission added: DataWrite on hr_case. Sensitivity escalation: internal → confidential.

Time to answer: ~3 seconds (version diff with canonical permission delta)

Q3: "Who granted the DataWrite?"

GET /api/v1/events?chain_id=chain-azuregraphrouter-001&event_type=chain_permission_expanded

Result: Event at 2026-01-30, actor: bob.chen@corp.com, change: hr_admin role added to SP sn-ticket-router, canonical impact: +DataWrite on hr_case (confidential, PII).

Time to answer: ~3 seconds (chain event with canonical impact)

Q4: "What were this Application's permissions before Day 30?"

GET /api/v1/execution-chains/chain-azuregraphrouter-001/versions?valid_at=2026-01-29

Result: Version N-1:

DataRead on incident_table (internal)
DataWrite on incident_table (internal)
DataRead on entra_users (confidential)
NonData on graph.microsoft.com (confidential)

No DataWrite on HR resources. No PII access.

Time to answer: ~2 seconds (point-in-time with canonical permission list)

Q5: "Was this Application actively executing during the exposure window?"

Same as Approach C — execution evidence on chain components.

Time to answer: ~3 seconds

Assessment: The combined approach answers all five questions with canonical precision. The CISO sees standardized permission types (DataWrite, DataRead) rather than internal role names (hr_agent_workspace). The temporal capability comes from execution_chains versioning. The vocabulary comes from OAA canonical types.

4.6 Forensic Query Comparison Matrix

Query	OAA Application Only	OAA Resource Only	execution_chains Only	execution_chains + OAA
Q1: Discovery	2s (canonical query)	3s (sub-resource traversal)	2s (blast radius domain)	2s (canonical + domain)
Q2: Temporal	UNANSWERABLE	UNANSWERABLE	3s (version diff)	3s (canonical version diff)
Q3: Attribution	UNANSWERABLE	UNANSWERABLE	3s (chain event)	3s (canonical chain event)
Q4: Historical state	UNANSWERABLE	UNANSWERABLE	2s (version lookup)	2s (canonical version lookup)
Q5: Execution	UNANSWERABLE	UNANSWERABLE	3s (evidence query)	3s (evidence query)
Total time	2s (1 of 5 answered)	3s (1 of 5 answered)	13s (5 of 5 answered)	13s (5 of 5 answered, canonical)

Which gives the fastest time-to-answer for the CISO?

For the discovery query (Q1): OAA Application model is equally fast and more precise (canonical permission types).

For the investigation queries (Q2-Q5): Only approaches with execution_chains versioning can answer them. OAA alone cannot.

For overall forensic investigation: The combined approach (execution_chains + OAA) provides the same speed as execution_chains alone, with better precision and auditor-ready vocabulary.

5. Risk: OAA Semantic Overload

5.1 The Problem

OAA's "Application" concept was designed for things like:

A SaaS platform (Salesforce, Jira, GitHub)
An internal web application (HR portal, support system)
A data system (Snowflake, S3 bucket)

These are things that humans use. They have login pages, dashboards, and user interfaces.

An automation chain is not something humans use. It is something that executes autonomously, without a human at the keyboard. Calling it an "Application" could confuse auditors and compliance officers who expect "Application" to mean "something I can log into."

5.2 The Confusion Scenarios

Scenario	Risk	Severity
GRC tool import. Automation chains exported as OAA Applications appear in the organization's application inventory alongside Salesforce, Jira, and the HR portal. An auditor reviewing the inventory asks: "What is 'AzureGraphRouter — Incident Routing'? Where do I log in?"	The auditor does not understand that this is an automation, not a human-facing application. Confusion adds time to the audit.	Medium
Access review campaign. IGA tool imports Applications from SecurityV0 and includes them in an access review campaign. The reviewer sees "Application: AzureGraphRouter" and is asked "Should user sn-ticket-router have DataWrite access to this application?" The reviewer does not understand the question.	The access review is meaningless because the reviewer does not understand that the "application" is an automation chain and the "user" is a service principal.	High
Executive reporting. CISO presents to the board: "We have 47 applications with DataWrite on HR data." The board asks: "Which vendors?" The CISO must explain that 38 of these are autonomous execution chains, not vendor applications.	Semantic confusion at the executive level undermines the credibility of the reporting.	Medium
Compliance attestation. SOC2 auditor asks: "How do you classify your applications?" If SecurityV0 exports automation chains as OAA Applications alongside actual source systems (Entra, ServiceNow), the distinction between a "platform" and an "automation running on that platform" is blurred.	The auditor may challenge whether automation chains are properly classified.	Low-Medium

5.3 Mitigation: Application Subtyping

The risk is manageable if automation chains are clearly distinguished from traditional applications:

// OAA Application for a traditional system
{
  "name": "ServiceNow Production",
  "application_type": "itsm_platform",
  "sv0_application_category": "source_system",
  // ... traditional application with human users
}

// OAA Application for an automation chain
{
  "name": "AzureGraphRouter — Incident Routing",
  "application_type": "automation_chain",
  "sv0_application_category": "autonomous_execution",
  "sv0_execution_mode": "autonomous",
  "sv0_trigger_type": "event_driven",
  "sv0_human_interaction": "none",
  // ... automation-specific metadata
}

Key mitigations:

Mitigation	Implementation	Risk Reduction
Distinct application_type	`automation_chain` vs `itsm_platform`, `identity_platform`, etc.	Queries can filter by type
Category field	`sv0_application_category`: `source_system` vs `autonomous_execution`	GRC tools can separate categories
Display conventions	Automation Applications always show an "automation" badge/prefix in UI and exports	Visual disambiguation
Export filtering	OAA export endpoint supports `?exclude_automations=true` for traditional Application inventory	Prevents pollution of existing inventories
Documentation	Each automation Application carries a `description` field explaining: "This is an autonomous execution chain that [trigger] → [action] → [destination]. It is not a human-facing application."	Auditor context

5.4 The Counter-Argument: Auditors Already Handle This

Modern enterprise environments already have "applications" that are not human-facing:

API gateways (Kong, Apigee) are "applications" in asset inventories
ETL pipelines (Informatica, dbt) are "applications" in vendor risk assessments
CI/CD systems (Jenkins, GitHub Actions) are "applications" in access reviews
Integration middleware (MuleSoft, Dell Boomi) are "applications" in SOC2 scope

Auditors in regulated industries routinely assess non-human-facing "applications." The key is proper classification and documentation, not avoidance of the term.

5.5 Risk Assessment

Risk Factor	Probability	Impact	Mitigation Effectiveness	Residual Risk
Auditor confusion	Medium	Medium	High (subtyping + documentation)	Low
GRC tool pollution	Medium	Low	High (export filtering)	Low
Access review confusion	High	Medium	Medium (requires IGA tool configuration)	Medium
Executive misinterpretation	Low	High	High (category-based reporting)	Low

Overall semantic overload risk: LOW-MEDIUM after mitigation.

The risk is real but manageable. The benefits of using an industry-standard concept (Application) for compliance attestation outweigh the risk of semantic confusion, provided the mitigations are implemented.

6. The "Execute" Permission Gap

6.1 The Problem

OAA defines 10 canonical permission types:

Permission	Meaning
DataRead	Read business data
DataWrite	Modify business data
DataCreate	Create new data records
DataDelete	Delete business data
MetadataRead	Read configuration/schema
MetadataWrite	Modify configuration/schema
MetadataCreate	Create configuration objects
MetadataDelete	Delete configuration objects
NonData	Actions that are not data operations
Uncategorized	Cannot classify

None of these mean "Execute" or "Trigger."

An automation chain does not merely "read" data from the incident table. It executes logic based on that data. The Business Rule fires, the Script Include runs JavaScript, the REST message sends an HTTP POST, the OAuth client authenticates, and the Service Principal queries the Graph API. This is execution — a fundamentally different operation from reading or writing data.

6.2 What "Execute" Means in the Automation Context

Execution Action	Best OAA Mapping	Why It's Inadequate
BR fires on table insert	NonData (trigger event)	"NonData" is a catch-all that includes "login," "export," and "trigger." The BR's execution is semantically distinct from a user logging in.
SI executes JavaScript	NonData (code execution)	The SI doesn't just "do a non-data thing" — it runs arbitrary code that can read, write, and call external systems. NonData understates the risk.
REST message POSTs to Graph API	NonData (API call)	An outbound HTTP POST to an external system is a high-risk action. NonData does not convey the egress/exfiltration risk.
OAuth client authenticates	NonData (authentication)	Authentication is the privilege boundary crossing. NonData is correct but does not capture the cross-system authority transfer.
SP queries Graph API	DataRead (reads user data)	This one maps correctly — it is a data read.
SP writes back to incident table	DataWrite (updates assignment_group)	This also maps correctly — it is a data write.

The first four actions — the execution-specific actions — all map to "NonData," which is OAA's generic bucket for anything that is not a CRUD operation on data. This is a problem because:

NonData is semantically overloaded. It covers everything from "user logged in" to "automation executed arbitrary JavaScript against an external API." These have vastly different risk profiles.
NonData does not convey execution authority. A CISO reviewing an Application's permissions sees "NonData" and must investigate further to understand whether it means "the application sends email notifications" or "the application executes JavaScript that can exfiltrate data to any external endpoint."
NonData does not support compliance queries. The CISO cannot query "show me all Applications that execute code" because code execution is not distinguished from other NonData actions.

6.3 SecurityV0's Permission Model Already Has "Execute"

SecurityV0's internal permission model (01-data-model.md) defines 7 normalized actions:

Action	Meaning	OAA Mapping
`create`	Make new records/resources	DataCreate
`read`	View/query existing data	DataRead
`update`	Modify existing records	DataWrite
`delete`	Remove records/resources	DataDelete
`execute`	Run/trigger actions	NonData (lossy)
`admin`	System-level configuration	MetadataWrite
`delegate`	Grant access to others	NonData (lossy)

Both execute and delegate are mapped to NonData in OAA, losing their distinct semantics.

6.4 Recommended Approach: OAA Extension, Not Replacement

SecurityV0 should NOT modify OAA's canonical types. OAA is an industry standard (or aspiring to be one), and modifying it would break interoperability.

Instead, SecurityV0 should extend the canonical vocabulary with sv0_ prefixed sub-types:

{
  "permissions": [
    {
      "name": "execute_script_include",
      "permission_type": ["NonData"],           // OAA canonical (for interop)
      "custom_properties": {
        "sv0_action_type": "execute",            // SecurityV0 extension
        "sv0_execution_category": "code_execution",
        "sv0_risk_indicators": ["arbitrary_code", "external_egress"],
        "sv0_execute_target": "graph.microsoft.com"
      }
    },
    {
      "name": "trigger_business_rule",
      "permission_type": ["NonData"],           // OAA canonical
      "custom_properties": {
        "sv0_action_type": "trigger",            // SecurityV0 extension
        "sv0_execution_category": "event_trigger",
        "sv0_trigger_source": "incident_table",
        "sv0_trigger_condition": "insert"
      }
    },
    {
      "name": "delegate_role_assignment",
      "permission_type": ["NonData"],           // OAA canonical
      "custom_properties": {
        "sv0_action_type": "delegate",           // SecurityV0 extension
        "sv0_delegation_scope": "role_assignment",
        "sv0_delegation_target": "hr_admin"
      }
    }
  ]
}

6.5 Proposed SecurityV0 Action Subtypes Under NonData

sv0_action_type	sv0_execution_category	Meaning	Risk Level
`execute`	`code_execution`	Runs arbitrary code (Script Include, Lambda, etc.)	Critical
`execute`	`api_call`	Makes outbound HTTP calls to external systems	High
`execute`	`flow_execution`	Executes a workflow/flow (Flow Designer, GitHub Action)	High
`trigger`	`event_trigger`	Fires on a data event (table insert, update, delete)	Medium
`trigger`	`schedule_trigger`	Fires on a schedule (cron, scheduled job)	Medium
`trigger`	`api_trigger`	Fires on an inbound API call (webhook, REST endpoint)	Medium
`delegate`	`role_assignment`	Can assign roles to other identities	Critical
`delegate`	`permission_grant`	Can grant permissions to other identities	Critical
`delegate`	`credential_issuance`	Can create or rotate credentials	Critical
`authenticate`	`cross_system_auth`	Authenticates to a different system (OAuth, SAML)	High
`authenticate`	`credential_exchange`	Exchanges one credential for another (OIDC federation)	High

6.6 How This Resolves the Gap

Before (OAA only):

Application AzureGraphRouter permissions:
  - NonData on graph.microsoft.com
  - NonData on incident_table (trigger)
  - DataRead on entra_users
  - DataWrite on incident_table

The CISO sees two "NonData" entries and must investigate to understand the risk.

After (OAA + SecurityV0 extensions):

Application AzureGraphRouter permissions:
  - NonData [sv0: execute/code_execution] on graph.microsoft.com
    Risk: arbitrary code execution with external egress
  - NonData [sv0: trigger/event_trigger] on incident_table
    Trigger: fires on insert to incident table
  - NonData [sv0: authenticate/cross_system_auth] on entra_id
    Auth: OAuth2 client_credentials to Microsoft Graph
  - DataRead on entra_users
  - DataWrite on incident_table (assignment_group)

The CISO now sees the execution risk profile without investigating each permission individually. The canonical OAA types remain for interoperability; the SecurityV0 extensions add the execution semantics.

6.7 Compliance Impact of the Extension

Framework	Without Execute Extension	With Execute Extension
CC6.1	"Application has NonData permissions" — vague	"Application executes code and authenticates cross-system" — precise
CC7.1	Cannot distinguish new NonData permissions by risk	Can alert on "Application gained code_execution permission"
CC8.1	Change tracked as "NonData permission added"	Change tracked as "execute/api_call permission added to external target"
A.5.9	Application classified by data permissions only	Application classified by execution risk (code execution, external egress)

The extension improves compliance attestation by making execution risk explicit in the permission vocabulary.

7. Risk Assessment: Three Approaches Compared

7.1 Risk Matrix

Risk Dimension	OAA Application Only	execution_chains Only	execution_chains + OAA
Semantic confusion	HIGH — automations called "Applications"	LOW — internal concept	MEDIUM — managed with subtyping
Temporal capability	NONE — snapshot-based	EXCELLENT — versioned	EXCELLENT — versioned with canonical snapshots
Forensic investigation	POOR — 1 of 5 questions answerable	EXCELLENT — 5 of 5	EXCELLENT — 5 of 5 with canonical precision
Compliance vocabulary	EXCELLENT — industry-standard	PARTIAL — internal vocabulary	EXCELLENT — industry-standard + temporal
Audit readiness	PARTIAL — current state only	MET (after Phase 2)	STRONGLY MET — canonical + temporal
Implementation complexity	LOW — export layer only	MEDIUM — new collection + versioning	MEDIUM-HIGH — both layers
Interoperability	HIGH — standard OAA format	LOW — proprietary format	HIGH — OAA export with extensions
Execute permission gap	HIGH — NonData catch-all	LOW — internal execute action	LOW — NonData + sv0 extensions
Maintenance burden	LOW — export layer only	MEDIUM — chain recompute pipeline	MEDIUM-HIGH — both pipelines
SCIM/OAA export safety	MEDIUM — automations may leak into user exports	LOW — chains isolated	LOW — chains isolated with typed exports

7.2 Risk Summary by Stakeholder

For the CISO (this role): The combined approach provides the strongest forensic and compliance posture. The OAA vocabulary makes findings and reports immediately comprehensible to auditors. The execution_chains versioning provides the temporal reconstruction capability required for incident response.

For the auditor: The combined approach speaks the auditor's language (Applications, canonical permissions, Resources) while providing the evidence depth (temporal versions, execution evidence, actor attribution) that audit examinations require.

For the developer: The combined approach has the highest implementation complexity but the clearest architectural separation — execution_chains is the persistence layer, OAA Application is the export/attestation layer.

For the founder: The combined approach validates the founder's insight — automations ARE more like Applications than Identities — while preserving the temporal and forensic capabilities that differentiate SecurityV0 from authorization catalog platforms like Veza.

8. Implementation Implications

8.1 Changes to Round 3 Recommendation

Round 3 recommended:

Phase 1: execution_chains collection with chain identity, composition, aggregate blast radius
Phase 2: execution_chain_versions with temporal snapshots

This analysis recommends adding to each phase:

Phase 1 additions:

Addition	Effort	Justification
Add OAA canonical permission aggregation to chain summary	+4h	Enable canonical permission queries at chain level
Add `oaa_export` field to chain document with Application-compatible structure	+4h	Support OAA-format export of chain data
Add `sv0_action_type` sub-classification for NonData permissions	+6h	Resolve Execute permission gap
Add `application_category` field (source_system vs autonomous_execution)	+1h	Prevent semantic overload in Application inventory

Phase 2 additions:

Addition	Effort	Justification
Include OAA canonical snapshot in chain versions	+4h	SOX ITGC: canonical permissions at any past date
Add canonical permission diff to chain version deltas	+4h	CC8.1: change impact in standardized vocabulary
Add `chain_permission_expanded` event type with canonical impact	+4h	CC7.1: monitoring with auditor-ready vocabulary

Total additional effort: ~27 hours across both phases.

This is incremental on top of the Round 3 estimates (Phase 1: 94h, Phase 2: 24-48h) and provides disproportionate compliance value.

8.2 Schema Extension: Chain Document with OAA Enrichment

// execution_chains collection — updated with OAA fields
{
  _id: "chain-azuregraphrouter-001",
  tenant_id: "uuid-...",
  chain_name: "AzureGraphRouter — Incident Routing",
  chain_type: "cross_system_automation",
  application_category: "autonomous_execution",     // NEW: distinguishes from source_system

  // Round 3 composition
  member_entities: [
    { entity_id: "uuid-br", role: "entry_point", entity_type: "identity", subtype: "business_rule" },
    { entity_id: "uuid-si", role: "executor", entity_type: "identity", subtype: "system_execution" },
    { entity_id: "uuid-rest", role: "target", entity_type: "resource", subtype: "rest_message" },
    { entity_id: "uuid-oauth", role: "auth", entity_type: "credential" },
    { entity_id: "uuid-sp", role: "destination_identity", entity_type: "identity", subtype: "service_principal" }
  ],

  // Round 3 aggregate
  aggregate_ownership_status: "degraded",
  aggregate_blast_radius: {
    resource_count: 4,
    max_sensitivity: "confidential",
    business_domains: ["it_ops", "hr"],
    contains_pii: true
  },

  // NEW: OAA canonical permission summary
  canonical_permissions: {
    summary: {
      DataRead: 2,    // incident_table, entra_users
      DataWrite: 1,   // incident_table (assignment_group)
      NonData: 3      // trigger, execute, authenticate
    },
    details: [
      {
        canonical_type: "DataRead",
        resource: "incident_table",
        resource_domain: "it_ops",
        resource_sensitivity: "internal"
      },
      {
        canonical_type: "DataRead",
        resource: "entra_users",
        resource_domain: "identity_platform",
        resource_sensitivity: "confidential"
      },
      {
        canonical_type: "DataWrite",
        resource: "incident_table",
        resource_domain: "it_ops",
        resource_sensitivity: "internal",
        write_fields: ["assignment_group"]
      },
      {
        canonical_type: "NonData",
        sv0_action_type: "trigger",
        sv0_execution_category: "event_trigger",
        resource: "incident_table",
        trigger_condition: "insert"
      },
      {
        canonical_type: "NonData",
        sv0_action_type: "execute",
        sv0_execution_category: "code_execution",
        resource: "graph.microsoft.com",
        risk_indicators: ["external_egress", "arbitrary_code"]
      },
      {
        canonical_type: "NonData",
        sv0_action_type: "authenticate",
        sv0_execution_category: "cross_system_auth",
        resource: "entra_id",
        auth_protocol: "oauth2_client_credentials"
      }
    ]
  },

  // Round 3 metadata
  composition_hash: "sha256:...",
  first_detected_at: ISODate("2025-03-10"),
  last_synced_at: ISODate("2026-02-13"),
  sync_version: 42
}

8.3 OAA Export Endpoint for Automation Chains

GET /api/v1/oaa/applications?application_category=autonomous_execution

Returns automation chains formatted as OAA Applications:

{
  "applications": [
    {
      "name": "AzureGraphRouter — Incident Routing",
      "application_type": "automation_chain",
      "description": "Autonomous execution chain: triggered by incident table insert, queries Microsoft Graph for user department, writes assignment_group back to incident. Cross-system: ServiceNow → Entra ID → ServiceNow.",

      "local_users": [
        {
          "name": "sn-ticket-router",
          "user_type": "service_principal",
          "is_active": true,
          "custom_properties": {
            "sv0_identity_subtype": "service_principal",
            "sv0_execution_mode": "autonomous",
            "sv0_chain_role": "destination_identity"
          }
        }
      ],

      "permissions": [
        {
          "name": "read_incidents",
          "permission_type": ["DataRead"],
          "custom_properties": {
            "sv0_source_permission": "itil",
            "sv0_resource_sensitivity": "internal"
          }
        },
        {
          "name": "write_incident_assignment",
          "permission_type": ["DataWrite"],
          "custom_properties": {
            "sv0_source_permission": "itil",
            "sv0_write_fields": ["assignment_group"],
            "sv0_resource_sensitivity": "internal"
          }
        },
        {
          "name": "read_entra_users",
          "permission_type": ["DataRead"],
          "custom_properties": {
            "sv0_source_permission": "User.Read.All",
            "sv0_resource_sensitivity": "confidential"
          }
        },
        {
          "name": "execute_graph_api_call",
          "permission_type": ["NonData"],
          "custom_properties": {
            "sv0_action_type": "execute",
            "sv0_execution_category": "api_call",
            "sv0_target_endpoint": "graph.microsoft.com",
            "sv0_risk_indicators": ["external_egress"]
          }
        }
      ],

      "resources": [
        {
          "name": "incident_table",
          "resource_type": "table",
          "custom_properties": {
            "sv0_business_domain": "it_ops",
            "sv0_sensitivity": "internal"
          }
        },
        {
          "name": "entra_users",
          "resource_type": "api_endpoint",
          "custom_properties": {
            "sv0_business_domain": "identity_platform",
            "sv0_sensitivity": "confidential"
          }
        }
      ],

      "identity_to_permissions": [
        {
          "identity": "sn-ticket-router",
          "identity_type": "local_user",
          "application_permissions": [
            { "permission": "read_incidents", "resources": ["incident_table"] },
            { "permission": "write_incident_assignment", "resources": ["incident_table"] },
            { "permission": "read_entra_users", "resources": ["entra_users"] },
            { "permission": "execute_graph_api_call", "resources": ["entra_users"] }
          ]
        }
      ],

      "custom_properties": {
        "sv0_chain_id": "chain-azuregraphrouter-001",
        "sv0_application_category": "autonomous_execution",
        "sv0_trigger_type": "event_driven",
        "sv0_trigger_source": "incident_table",
        "sv0_cross_system": true,
        "sv0_systems_involved": ["servicenow", "entra_id"],
        "sv0_ownership_status": "degraded",
        "sv0_active_findings": 3,
        "sv0_last_execution_at": "2026-02-13T14:00:00Z",
        "sv0_execution_count_30d": 847
      }
    }
  ]
}

This OAA-compatible export enables:

Import into GRC tools as an "Application" asset
Cross-system permission queries using canonical types
Integration with Veza or similar authorization graph platforms
Compliance reporting in industry-standard vocabulary

9. The Founder's Insight: Full Analysis

9.1 "Script Include Looks More Like an Application, Not Identity"

Assessment: Partially correct, but nuanced.

A Script Include is a component of an Application, not the Application itself. The full automation chain (BR → SI → REST → OAuth → SP) is the Application. The SI is one component — the execution engine.

In SecurityV0's current model, the SI is modeled as an Identity (identity_subtype: system_execution). This is correct for the entity level — the SI has roles (via RUNS_AS), permissions (inherited from the SP), and execution evidence. But at the chain level, the SI is a component of a larger Application.

The resolution is that the same entity (SI) can be:

An Identity in the entity graph (for entity-level analysis, findings, temporal tracking)
A component of an Application in the OAA export (for compliance attestation, permission cataloging)

These are not contradictory. They are different views of the same reality at different abstraction levels.

9.2 "Autonomous Execution Could Be Treated as Application, or Collection of Applications, Identities, Roles, Data Modifications"

Assessment: Correct — and the recommended approach models it as all of these.

Abstraction	How SecurityV0 Models It	Purpose
Application	OAA export of execution_chain	Compliance attestation, asset inventory, cross-system permission queries
Collection of Identities	execution_chain.member_entities (BR, SI, SP)	Composition tracking, entity-level findings, temporal versioning
Roles	Roles held by component identities (via HAS_ROLE, RUNS_AS)	Permission derivation, scope drift detection
Data modifications	Resources in blast radius with DataWrite canonical permission	Data flow analysis, PII impact assessment

The execution_chains collection with OAA enrichment captures all of these perspectives simultaneously. The chain is the unifying concept; the OAA Application is the export format; the component entities, roles, and resources are the internal structure.

9.3 "Incident Trigger Could Be 'Data' or 'Resource'"

Assessment: Correct — and OAA models this well.

The incident table insert that triggers the Business Rule is a Resource in OAA terms — the BR has a NonData (trigger) permission on the incident_table resource. The data modification (updating assignment_group) is a DataWrite permission on the same resource.

The same resource (incident_table) appears twice in the permission set with different canonical types:

NonData (sv0: trigger/event_trigger) — the BR fires when data is inserted
DataWrite — the SP writes assignment_group back to the table

This dual-permission modeling on a single resource is exactly what OAA was designed for, and it accurately captures the automation's relationship to the incident table.

9.4 "Updating Data Later Like Incident Table — Looks Like a Change to 'Data' or 'Resource'"

Assessment: Correct — and the DataWrite canonical type captures this.

When the automation writes back to the incident table (updating assignment_group), this is a DataWrite on the incident_table resource. OAA captures it precisely.

What OAA does not capture is the data flow direction: the automation reads from the incident table (DataRead), sends data to Microsoft Graph (NonData/execute), receives data from Microsoft Graph (DataRead on entra_users), and writes back to the incident table (DataWrite). This is a data flow loop that involves data leaving the organization's perimeter (to graph.microsoft.com) and returning.

SecurityV0's execution_chains model captures this flow through the ordered chain composition (BR → SI → REST → OAuth → SP). OAA's permission model captures the endpoints (DataRead on incident, DataWrite on incident, DataRead on entra_users) but not the flow between them.

10. Recommendations

10.1 Primary Recommendation: Dual-Layer Approach

Implement the Round 3 execution_chains collection as the persistence and forensic layer. Add OAA canonical permission vocabulary as the compliance and attestation layer. These are complementary, not competing.

10.2 Specific CISO Requirements

Requirement	Priority	Approach
Chain-level canonical permission queries	P1	Add `canonical_permissions` to execution_chain documents
Auditor-ready finding language	P1	Chain findings use OAA canonical types in explanations
Asset inventory compatibility	P1	OAA Application export with `application_category` subtyping
Execute permission disambiguation	P1	`sv0_action_type` extension under NonData
Temporal canonical snapshots	P2	Include OAA canonical snapshot in chain versions
Canonical permission diff in events	P2	Chain events express canonical impact
GRC tool export filtering	P2	Export endpoint supports category filtering
SCIM export safety	P2	Automation chains excluded from SCIM User exports

Do NOT model automations as OAA Resources. The "Automation as Resource" approach inverts the semantic relationship and loses chain composition. Automations are actors, not targets.
Do NOT replace execution_chains with OAA Applications. OAA has no temporal capability, no change tracking, no execution evidence, and no ownership modeling. It is a catalog, not a forensic tool.
Do NOT modify OAA's canonical permission types. Adding "Execute" to OAA would break interoperability. Use sv0_ prefixed extensions in custom_properties instead.
Do NOT expose automation chains as SCIM Users. Automations are not users. The SCIM API should continue to expose source-system identities (SPs, OAuth apps, machine accounts). Automation chains should be exposed via the OAA Application export endpoint.
Do NOT defer the Execute permission extension. The NonData catch-all is a compliance communication gap today. Every audit conversation about automation permissions will require manual explanation of what "NonData" means. The sv0_action_type extension resolves this at low implementation cost.

10.4 Decision Matrix for the Founder

Question	Recommended Answer	Rationale
Should automations be modeled as OAA Applications?	Yes, as an export/attestation layer	Applications are industry-standard asset types that auditors understand
Should this replace `execution_chains`?	No	OAA has no temporal, ownership, or forensic capability
Should automations be modeled as OAA Resources?	No	Semantically incorrect — automations are actors, not targets
Should we add "Execute" to OAA canonical types?	No — extend, don't modify	Use `sv0_action_type` in custom_properties
Should automation chains appear in SCIM exports?	No	SCIM is for identity objects; automations are composite entities
Is there risk in calling automations "Applications"?	Yes, but manageable	Subtyping + documentation mitigates confusion

11. Compliance Readiness Timeline (Updated from Round 3)

After Phase 1 (execution_chains + OAA enrichment)

Control	Status	Evidence
CC6.1	PARTIAL → IMPROVED	Chain identity with canonical permission vocabulary. Current-state attestation in OAA terms.
CC7.1	PARTIAL → IMPROVED	Chain-level findings with canonical permission impact. "Application gained DataWrite on confidential resource."
CC8.1	PARTIAL	Chain scope defined. Change tracking via composition hash + canonical permission comparison.
A.5.9	NOT MET → STRONGLY MET	Chains exportable as OAA Applications — industry-standard asset type with canonical permissions.
SOX ITGC	PARTIAL	Current inventory in canonical terms. Historical reconstruction still requires Phase 2.

After Phase 2 (chain versions + OAA canonical snapshots)

Control	Status	Evidence
CC6.1	MET	Chain state at any T with canonical permissions. "On Day 30, Application had DataRead on it_ops, DataRead on identity_platform."
CC7.1	MET	Temporal chain findings with canonical impact. "Application gained DataWrite on hr_case (confidential, PII) on 2026-01-30."
CC8.1	MET	Chain events with canonical impact + actor attribution. Full change history in auditor-ready vocabulary.
A.5.9	MET	Full lifecycle: creation, changes, deletion with canonical permission snapshots at each version.
SOX ITGC	MET	Canonical permission state at any date within retention window. Direct lookup, no reconstruction.

12. Dissenting Considerations

12.1 "OAA Is Not a Real Standard — Why Align?"

Counterargument: OAA is Veza's proprietary specification, not an IETF/ISO standard. It has no formal standards body governance. Aligning to it could lock SecurityV0 into a vendor-specific vocabulary.

Response: The alignment is to OAA's concepts (Application, canonical permissions, Resources), not to Veza's API or platform. The 10 canonical permission types (DataRead, DataWrite, etc.) are generic CRUD categories that any authorization system would recognize. If a competing standard emerges (and the IETF draft-ietf-scim-roles-entitlements is the closest candidate), SecurityV0's canonical types can be remapped. The risk of conceptual alignment is low; the risk of NOT having canonical permissions is the compliance communication gap documented throughout this analysis.

12.2 "The Execute Extension Adds Complexity Without Standard Backing"

Counterargument: Adding sv0_action_type under NonData is a proprietary extension that other tools will not understand. It adds schema complexity without interoperability benefit.

Response: The extension is placed in custom_properties, which OAA explicitly supports. Any OAA consumer that does not understand sv0_action_type will simply ignore it and see "NonData" — the standard canonical type. The extension adds precision for SecurityV0's own compliance reporting without breaking OAA interoperability. The alternative — leaving all execution actions as undifferentiated "NonData" — is worse for compliance communication.

12.3 "The Combined Approach Is Over-Engineered for an MVP"

Counterargument: SecurityV0 has one connector pair (Entra + ServiceNow) and a handful of automation chains. The combined approach adds ~27 hours to an already substantial implementation. Ship execution_chains first, add OAA later.

Response: The OAA enrichment is incremental — it adds canonical type fields to documents that already exist. The bulk of the implementation effort is in execution_chains (94h Phase 1 + 24-48h Phase 2). Adding canonical permissions at chain construction time is 4 additional hours. The compliance benefit is immediate: the first audit conversation will ask about permissions in terms the auditor understands (DataWrite on HR data, not hr_agent_workspace role). Deferring OAA enrichment means the first audit conversation requires manual translation.

That said, if implementation capacity is constrained, the OAA enrichment can be added in Phase 1.5 (between Phase 1 and Phase 2) without architectural changes — it is an additive enrichment to existing chain documents.

13. Summary Position

The founder's insight — that automations resemble OAA Applications rather than Identities — is architecturally correct and compliance-valuable. An automation chain is a composite execution environment with identities, permissions, and resources, which maps to OAA's Application concept far more naturally than to its Local User concept.

However, OAA's Application model is necessary but not sufficient. It provides the compliance vocabulary (canonical permissions, typed resources) but lacks the forensic capability (temporal versions, change tracking, execution evidence, ownership) that SecurityV0 requires for audit readiness.

The recommended approach is dual-layer:

Persistence layer: execution_chains collection (Round 3 recommendation, unchanged) — provides stable identity, temporal versioning, composition tracking, chain-level findings, and forensic investigation capability.
Attestation layer: OAA canonical permission enrichment on chain documents + OAA Application export endpoint — provides industry-standard vocabulary for compliance communication, asset inventory compatibility, and cross-system permission queries.
Execute extension: sv0_action_type sub-classification under NonData — resolves the gap between OAA's CRUD-oriented permission model and SecurityV0's execution-oriented analysis, without modifying the OAA standard.

The combined approach satisfies all five compliance frameworks analyzed (CC6.1, CC7.1, CC8.1, A.5.9, SOX ITGC) at Phase 2 completion, provides sub-second forensic investigation for all five breach scenario questions, and positions SecurityV0 as both a forensic tool (internal execution_chains) and an interoperable authorization catalog (OAA Application export).

The incremental cost of OAA enrichment (~27 hours across both phases, on top of the Round 3 estimate) is justified by the compliance communication improvement. The first auditor who asks "what can this automation do?" will receive an answer in canonical terms (DataWrite on confidential HR resource) rather than internal terms (hr_agent_workspace role with incident.write ACL). That translation — from internal vocabulary to audit vocabulary — is what OAA alignment provides.

Build the chains. Enrich them with OAA canonical types. Export them as Applications. Version them with canonical snapshots. This is the path to audit-ready, forensic-capable, interoperable automation tracking.

This analysis was prepared from the CISO perspective for the SecurityV0 automation-analysis team, Round 4. It builds on the Round 3 CISO analysis (03-automation-persistence-ciso.md) and the team synthesis (03-automation-persistence-synthesis.md). It addresses the founder's specific question about OAA alignment for automation modeling and concludes that OAA Application modeling enriches the execution_chains approach without replacing it. The combined approach provides the strongest compliance, forensic, and interoperability posture of all options evaluated.

Executive Summary​

1. Security Implications of "Automation as Application"​

1.1 What Changes in the OAA Application Model​

1.2 How This Changes the Compliance Mapping from Round 3​

1.3 Impact on the Incident Response Scenario (Day 0-91 Breach)​

1.4 Can the CISO Query "All Applications of Type Automation That Have DataWrite on HR Data"?​

2. The Data/Resource Perspective​

2.1 OAA's View: Application with DataRead and DataWrite​

2.2 What Is Sufficient, and What Is Missing​

2.3 The Privilege Escalation Path Question​

2.4 Incident Table as Resource, Entra Users as Resource​

3. Compliance Impact of OAA Alignment​

3.1 SOC2 CC6.1 — Logical and Physical Access Controls​

3.2 SOC2 CC7.1 — System Monitoring​

3.3 SOC2 CC8.1 — Change Management​

3.4 ISO 27001 A.5.9 — Inventory of Information and Associated Assets​

3.5 SOX ITGC — IT General Controls​

3.6 Compliance Summary Matrix​

4. Forensic Query Capability: Day 0-91 Breach Scenario​

4.1 Setup (Identical to Round 3)​

4.2 Approach A: "Automation as Application" (OAA-Only)​

4.3 Approach B: "Automation as Resource" (OAA-Only)​

4.4 Approach C: Round 3 execution_chains (Without OAA)​

4.5 Approach D: execution_chains + OAA Canonical Vocabulary (Recommended)​

4.6 Forensic Query Comparison Matrix​

5. Risk: OAA Semantic Overload​

5.1 The Problem​

5.2 The Confusion Scenarios​

5.3 Mitigation: Application Subtyping​

5.4 The Counter-Argument: Auditors Already Handle This​

5.5 Risk Assessment​

6. The "Execute" Permission Gap​

6.1 The Problem​

6.2 What "Execute" Means in the Automation Context​

6.3 SecurityV0's Permission Model Already Has "Execute"​

6.4 Recommended Approach: OAA Extension, Not Replacement​

6.5 Proposed SecurityV0 Action Subtypes Under NonData​

6.6 How This Resolves the Gap​

6.7 Compliance Impact of the Extension​

7. Risk Assessment: Three Approaches Compared​

7.1 Risk Matrix​

7.2 Risk Summary by Stakeholder​

8. Implementation Implications​

8.1 Changes to Round 3 Recommendation​

8.2 Schema Extension: Chain Document with OAA Enrichment​

8.3 OAA Export Endpoint for Automation Chains​

9. The Founder's Insight: Full Analysis​

9.1 "Script Include Looks More Like an Application, Not Identity"​

9.2 "Autonomous Execution Could Be Treated as Application, or Collection of Applications, Identities, Roles, Data Modifications"​

9.3 "Incident Trigger Could Be 'Data' or 'Resource'"​

9.4 "Updating Data Later Like Incident Table — Looks Like a Change to 'Data' or 'Resource'"​

10. Recommendations​

10.1 Primary Recommendation: Dual-Layer Approach​

10.2 Specific CISO Requirements​

10.3 What This Analysis Does NOT Recommend​

10.4 Decision Matrix for the Founder​

11. Compliance Readiness Timeline (Updated from Round 3)​

After Phase 1 (execution_chains + OAA enrichment)​

After Phase 2 (chain versions + OAA canonical snapshots)​

12. Dissenting Considerations​

12.1 "OAA Is Not a Real Standard — Why Align?"​

12.2 "The Execute Extension Adds Complexity Without Standard Backing"​

12.3 "The Combined Approach Is Over-Engineered for an MVP"​

13. Summary Position​

Executive Summary

1. Security Implications of "Automation as Application"

1.1 What Changes in the OAA Application Model

1.2 How This Changes the Compliance Mapping from Round 3

1.3 Impact on the Incident Response Scenario (Day 0-91 Breach)

1.4 Can the CISO Query "All Applications of Type Automation That Have DataWrite on HR Data"?

2. The Data/Resource Perspective

2.1 OAA's View: Application with DataRead and DataWrite

2.2 What Is Sufficient, and What Is Missing

2.3 The Privilege Escalation Path Question

2.4 Incident Table as Resource, Entra Users as Resource

3. Compliance Impact of OAA Alignment

3.1 SOC2 CC6.1 — Logical and Physical Access Controls

3.2 SOC2 CC7.1 — System Monitoring

3.3 SOC2 CC8.1 — Change Management

3.4 ISO 27001 A.5.9 — Inventory of Information and Associated Assets

3.5 SOX ITGC — IT General Controls

3.6 Compliance Summary Matrix

4. Forensic Query Capability: Day 0-91 Breach Scenario

4.1 Setup (Identical to Round 3)

4.2 Approach A: "Automation as Application" (OAA-Only)

4.3 Approach B: "Automation as Resource" (OAA-Only)

4.4 Approach C: Round 3 `execution_chains` (Without OAA)

4.5 Approach D: `execution_chains` + OAA Canonical Vocabulary (Recommended)

4.6 Forensic Query Comparison Matrix

5. Risk: OAA Semantic Overload

5.1 The Problem

5.2 The Confusion Scenarios

5.3 Mitigation: Application Subtyping

5.4 The Counter-Argument: Auditors Already Handle This

5.5 Risk Assessment

6. The "Execute" Permission Gap

6.1 The Problem

6.2 What "Execute" Means in the Automation Context

6.3 SecurityV0's Permission Model Already Has "Execute"

6.4 Recommended Approach: OAA Extension, Not Replacement

6.5 Proposed SecurityV0 Action Subtypes Under NonData

6.6 How This Resolves the Gap

6.7 Compliance Impact of the Extension

7. Risk Assessment: Three Approaches Compared

7.1 Risk Matrix

7.2 Risk Summary by Stakeholder

8. Implementation Implications

8.1 Changes to Round 3 Recommendation

8.2 Schema Extension: Chain Document with OAA Enrichment

8.3 OAA Export Endpoint for Automation Chains

9. The Founder's Insight: Full Analysis

9.1 "Script Include Looks More Like an Application, Not Identity"

9.2 "Autonomous Execution Could Be Treated as Application, or Collection of Applications, Identities, Roles, Data Modifications"

9.3 "Incident Trigger Could Be 'Data' or 'Resource'"

9.4 "Updating Data Later Like Incident Table — Looks Like a Change to 'Data' or 'Resource'"

10. Recommendations

10.1 Primary Recommendation: Dual-Layer Approach

10.2 Specific CISO Requirements

10.3 What This Analysis Does NOT Recommend

10.4 Decision Matrix for the Founder

11. Compliance Readiness Timeline (Updated from Round 3)

After Phase 1 (execution_chains + OAA enrichment)

After Phase 2 (chain versions + OAA canonical snapshots)

12. Dissenting Considerations

12.1 "OAA Is Not a Real Standard — Why Align?"

12.2 "The Execute Extension Adds Complexity Without Standard Backing"

12.3 "The Combined Approach Is Over-Engineered for an MVP"

13. Summary Position