Partner & Customer Space
Securityv0 Deployment Integration Requirements
Entra ID + ServiceNow
Overview
Securityv0 connects to enterprise systems to discover non-human identities, automation workflows, and cross-system execution paths. It analyzes how service identities, integrations, and automated processes interact across systems to identify:
- standing execution authority
- ownership and governance gaps
- cross-system automation paths
- opportunities to reduce exposure
Securityv0 operates in read-only mode and does not modify source systems.
Systems Supported in This Deployment
This deployment configuration includes integrations with:
- Microsoft Entra ID
- ServiceNow
These integrations allow Securityv0 to map identity relationships and automation activity across cloud infrastructure and enterprise workflow systems.
Integration Requirements
Securityv0 requires limited read-only access to each system.
| System | Requirement |
|---|---|
| Microsoft Entra ID | One App Registration with read-only Microsoft Graph permissions |
| Azure | Reader RBAC role on relevant subscriptions |
| ServiceNow | One dedicated read-only API user |
| Securityv0 Platform | API key for data submission |
All credentials are used only for discovery of identity relationships and automation metadata.
Authentication Models
| System | Authentication |
|---|---|
| Microsoft Entra | OAuth2 client credentials (application identity) |
| ServiceNow | HTTPS Basic Authentication using a dedicated API user |
| Securityv0 Platform | API key |
Microsoft Entra Access
The integration uses a Microsoft Entra application identity to query Microsoft Graph.
Required permissions:
| Permission | Purpose |
|---|---|
Application.Read.All | Discover service principals and application identities |
Directory.Read.All | Retrieve directory objects used for identity correlation |
User.Read.All | Validate ownership of service identities |
Optional:
| Permission | Purpose |
|---|---|
AuditLog.Read.All | Retrieve sign-in activity for service identities |
These permissions allow Securityv0 to discover:
- service principals and application identities
- identity ownership relationships
- role assignments and OAuth grants
- optional identity execution activity
All permissions are read-only.
Azure RBAC Requirement
The connector requires the Reader role on Azure subscriptions that contain workloads interacting with the identities being analyzed.
This access allows Securityv0 to resolve:
- managed identities
- role assignments
- resource relationships
These signals are used to compute authority paths between automated workloads and cloud resources.
ServiceNow Access
Securityv0 requires read-only access to ServiceNow tables associated with integrations and automation workflows.
Examples include:
| Table Category | Purpose |
|---|---|
| OAuth integrations | Identify ServiceNow API credentials |
| REST message definitions | Discover outbound API integrations |
| Automation scripts and flows | Identify automated execution logic |
| User metadata | Validate ownership of automations |
This information allows the platform to detect automations that invoke external systems such as Microsoft Graph or Azure APIs.
Data Access and Privacy
The platform analyzes identity and automation metadata, not operational business records.
Examples of accessed data
From Entra:
- service principal identifiers and metadata
- identity ownership relationships
- permissions and OAuth grants
- optional sign-in activity
From ServiceNow:
- automation definitions
- API integration metadata
- creator or owner identity metadata
Examples of excluded data
The platform does not ingest business content, such as:
- incident descriptions
- ticket conversations
- attachments
- workflow payloads
Only information required to analyze identity relationships and automation paths is accessed.
Deployment Summary (15-20 min setup)
A standard deployment typically requires:
- Creating a Microsoft Entra App Registration
- Granting read-only Microsoft Graph permissions
- Assigning the Reader RBAC role on relevant Azure subscriptions
- Creating a read-only ServiceNow API user
- Providing a Securityv0 platform API key
Once configured, the platform begins discovering identity relationships and automation execution paths across integrated systems.
Outcome
After deployment, Securityv0 continuously analyzes how automated identities and workflows operate across integrated systems.
The platform surfaces:
- Execution authority paths
How service identities, automations, and integrations invoke APIs and access resources across systems.
- Scope drift
Changes in identity privileges or automation behavior that expand the reachable systems or data domains over time.
- Ownership gaps
Identities, integrations, or automations that operate without a valid accountable owner.
- Governance instability
Conditions such as orphaned identities, inactive owners, or unreviewed automation paths.
- Recommended risk reducers
Structural changes that materially reduce execution exposure, such as:
- assigning a valid owner
- restricting execution scope
- removing unnecessary authority paths
- tightening identity boundaries
Securityv0 focuses on standing execution authority created by automation and AI-enabled systems, helping security teams understand and reduce exposure created by machine-operated workflows.
Inetum + Deloitte Questions prep
Positioning
Where we win: Authority path visibility across systems.
Identity governance → who owns the identity Securityv0 → what that identity actually executes across systems
Our model: we are the platform (ok to whitelabel)
Securityv0 assessment ↓ Findings from authority paths ↓ Partner sells remediation services
Q&A
**How we connect: Authentication model**
Some large organizations do not allow service accounts, so certificate or API authentication may be required.
read-only least privilege tenant-level integration no agent no write permissions
**What signal we collect: Discovery mechanism**
Our discovery model:
- Discover runtime identities (service principals, automation identities etc)
- Discover automation definitions (workflows, AI agents etc)
- Map reachable systems and APIs
- Reconstruct execution authority paths (identity → automation → system → data domain)
- Evaluate risk conditions (scope drift, orphaned automation, cross-system authority, sensitive data egress etc).
We reconstruct execution authority and the chain of custody by combining signals from:
- runtime identity relationships
- workflow definitions
- automation configurations
- system-to-system calls
- execution evidence
From these signals we build authority paths, showing runtime identity, automation flow, reachable systems, and reachable sensitive data domains.
Then we risk conditions like orphaned identities, cross-system authority chains, scope drift, external or LLM egress, and sensitive data reach.
What data are we pulling and from where?
How do we reconstruct the automation?
How reliable are the findings?
100% deterministic and replayable.
**How risk is determined: Risk detection logic - how Securityv0 determines that an automation should not perform an action if the underlying system already granted permission.**
Traditional systems validate permissions. Securityv0 evaluates systemic exposure: • orphaned identities • unbounded execution scope • cross-system authority chains • AI workflows reaching sensitive systems
**Automation scope - clear boundaries on what types of automation are covered**
AWS scope - clarification was requested on whether AWS support refers to:
or
- general cloud automation environments.