Skip to main content

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:

  1. Discover runtime identities (service principals, automation identities etc)
  2. Discover automation definitions (workflows, AI agents etc)
  3. Map reachable systems and APIs
  4. Reconstruct execution authority paths (identity → automation → system → data domain)
  5. 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**
- Microsoft Foundry - Microsoft Azure and EntraID - ServiceNow - AWS (?) - GitHub - Any other automation system can be plugged into our canonical data model using the same read-only metadata-only approach.
AWS scope - clarification was requested on whether AWS support refers to:
- AI agent environments equivalent to Azure Foundry

or

  • general cloud automation environments.