Securityv0 — Response to Inetum
Version 1 — Executive Summary (for email / call)
Re: Authentication and integration approach
On authentication — we follow the vendor-recommended patterns for each platform we integrate with. For Azure and Entra ID, that means OAuth 2.0 with client credentials on an App Registration. For AWS, it's cross-account IAM roles with temporary credentials. For ServiceNow, OAuth 2.0 client credentials. Each of these is the standard, production-grade integration pattern recommended by the platform vendor.
We can absolutely support more advanced authentication models — client certificates (X.509), Managed Identities for Azure-hosted deployments, Mutual TLS for ServiceNow, IAM Roles Anywhere for AWS. These are all within our architecture. That said, in our experience, starting with the standard client credentials pattern gets customers to first results fastest. The more complex auth modes (mTLS, federated identity, etc.) tend to add setup time on the customer side without changing what Securityv0 actually accesses — which is always read-only metadata, with least-privilege permissions.
Our recommendation: start with the standard integration, get the first assessment running, and upgrade the auth method later if the customer's security team requires it. We're happy to walk through the specifics for any platform on a call.
Version 2 — Full Technical Response (internal / deep dive)
Date: 2026-03-10 (last refreshed 2026-05-14 — AWS section updated to reflect shipped status) Status: DRAFT — subject to revision after third-party review of integration approaches. Note: Section 5 (AWS Scope) was originally written when the AWS connector was on the roadmap; it was corrected on 2026-05-14 to reflect that the AWS connector shipped in 2026-05. Recipients: Laureano Rapoport, Ignacio Casas, Nicolas Fernandez (Inetum) From: Securityv0 Engineering
Purpose
This document responds to the technical questions raised during the Securityv0–Inetum meeting on 2026-03-10. It covers authentication models, discovery mechanics, risk detection logic, automation scope, and AWS scope.
1. Authentication Model
How Securityv0 connects to customer environments
Securityv0 connectors operate under strict security constraints:
- Read-only — no write permissions, no configuration changes
- Metadata-only — identity relationships and automation definitions, not business data
- Least-privilege — minimal permissions scoped to discovery requirements
- No agent deployment — connectors call platform APIs remotely via standard HTTPS. In the SaaS model, nothing is installed in the customer environment. A customer-hosted deployment option is also available (see below).
- Revocable — customer controls all credentials and can revoke access at any time
Deployment model
Securityv0 connectors can run in two modes:
- SaaS-hosted (default): Connectors run in Securityv0's cloud infrastructure and call customer APIs remotely. Nothing is installed in the customer environment. Credentials are stored in our vault.
- Customer-hosted: For organizations that require all processing to remain within their network boundary, connectors can be deployed inside the customer's environment (e.g., as an Azure Container Instance or Kubernetes pod). This enables Managed Identity auth and ensures no metadata leaves the customer's infrastructure.
The deployment model determines which authentication methods are available (see below).
Authentication methods per platform
Our production connectors currently use OAuth2 client credentials with client secret (Azure) and HTTP Basic Auth (ServiceNow). We are expanding authentication support to accommodate enterprise security policies that restrict service accounts or require certificate-based authentication. The methods marked "available now" are in production; others are planned for near-term delivery.
Microsoft Entra ID / Azure / Azure AI Foundry
All Azure-based integrations use the Microsoft Identity Platform. The following methods are supported or planned:
| Method | Status | Description | Stored Secret? |
|---|---|---|---|
| Client Secret | Available now | OAuth2 client credentials with a client secret. Used for current evaluations. | Yes — secret must be rotated |
| Client Certificate (X.509) | Planned (near-term) | App Registration authenticated with an X.509 certificate. Private key stays with the connector; only the public certificate is registered in Entra. | No secret — certificate-based |
| Managed Identity | Planned (near-term) | For customer-hosted deployments running inside Azure. Credentials are platform-managed with automatic rotation. | No credential management needed |
| Workload Identity Federation | Planned | For SaaS-hosted deployments. Uses OIDC federation — no secret or certificate stored in the customer's Entra tenant at all. | Zero secrets in customer tenant |
Our recommendation: Client Certificate for SaaS-hosted deployments. Managed Identity for customer-hosted deployments inside Azure. Both are Microsoft's recommended production patterns. Client Secret remains available for rapid evaluations.
What doesn't change: Regardless of authentication method, the required API permissions remain the same:
Application.Read.All,Directory.Read.All,User.Read.All(Microsoft Graph)ReaderRBAC role on relevant Azure subscriptionsAzure AI Useron AI Services accounts (for Foundry discovery)- Optional:
AuditLog.Read.Allfor dormancy detection
ServiceNow
| Method | Status | Description | Stored Secret? |
|---|---|---|---|
| Basic Authentication | Available now | Username and password. Used for current evaluations. | Yes — password stored |
| OAuth 2.0 Client Credentials | Planned (near-term) | Standard OAuth2 flow. Short-lived access tokens (30-minute TTL). | Client secret is stored, but API tokens are short-lived |
| Mutual TLS (mTLS) | Planned | Certificate-based authentication. ServiceNow maps the certificate to a read-only API user. | No password — certificate-based |
Our recommendation: OAuth 2.0 Client Credentials for most deployments (requires ServiceNow Washington DC release or later). Mutual TLS for environments that require certificate-based authentication. Basic Auth remains available for rapid evaluations.
What doesn't change: The ServiceNow API user (however authenticated) requires read-only access to integration and automation tables: OAuth registrations, REST message definitions, automation scripts/flows, and user metadata. Access is limited to automation and integration metadata — not bulk incident data, ticket conversations, or attachments.
For organizations that do not allow service accounts
Several approaches avoid traditional service accounts entirely:
- Azure Managed Identity: No service account — the identity is tied to the Azure resource running the connector
- Azure Workload Identity Federation: No credentials stored in the customer's tenant — trust is based on identity federation
- Azure/ServiceNow Client Certificates: The credential is a certificate, not an account with a password
- ServiceNow mTLS: Authentication through PKI infrastructure, mapped to a minimal-privilege API identity
We are happy to work with Inetum's security team to select the approach that best fits their (and their customers') policies.
2. Discovery Mechanism
What signals we collect and how
Securityv0 discovery follows a five-step process:
Step 1 — Discover runtime identities Query identity systems (Entra ID, ServiceNow user tables) for non-human identities: service principals, app registrations, managed identities, API integration users, automation accounts.
Step 2 — Discover automation definitions Query automation platforms for workflow definitions: AI agent configurations (Foundry), ServiceNow flows and scripts, scheduled jobs, REST integrations, outbound API connections.
Step 3 — Map reachable systems and APIs For each automation, identify what systems and APIs it can reach. This includes: configured connections, API endpoints, OAuth grants, role assignments, and resource access.
Step 4 — Reconstruct execution authority paths
Combine the signals from steps 1-3 into authority paths: chains that show identity → automation → target system → data domain. These paths represent what each non-human identity can actually execute across systems.
Step 5 — Evaluate risk conditions Apply deterministic evaluation rules to the authority paths. Risk conditions include: orphaned identities (no valid owner), cross-system authority chains, scope drift (permissions that expanded over time), sensitive data reach, and dormant identities with standing authority.
What data is accessed
| Source | Data accessed | Data NOT accessed |
|---|---|---|
| Entra ID | Service principal metadata, ownership (including owner UPN/email and account status), role assignments, OAuth grants, sign-in activity (counts) | Passwords, MFA configuration, personal files, mailbox content |
| Azure ARM | Resource metadata, RBAC assignments, managed identity bindings | Resource content, storage data, application data |
| Azure AI Foundry | Agent definitions, connections, execution metadata | Prompts, model outputs, inference data, training data |
| ServiceNow | Integration definitions, flow/script metadata (including trigger descriptions), API registrations, automation owner metadata | Ticket conversations, attachments, workflow payloads, bulk business records |
Note on personal data: The platform reads a limited set of identity-related personal data (owner email addresses and account status) solely to determine whether automation owners are active. It also reads automation trigger descriptions from ServiceNow to classify workflow types. No bulk user enumeration or business content access occurs.
How reliable are the findings?
Findings are deterministic and evidence-backed — no machine learning, probabilistic scoring, or behavioral heuristics:
- Every finding traces back to specific API responses from source systems
- Findings are replayable — re-running the same connector against the same environment produces the same results
- Each finding includes an evidence chain showing the exact identity, automation, and system relationships that created the exposure
Evidence is categorized by confidence level. Direct evidence comes from explicit API data (e.g., a role assignment or an OAuth grant). Structural evidence is inferred from system relationships (e.g., an automation's reachable scope based on its configured connections). Temporal evidence is derived from activity signals (e.g., execution frequency, last sign-in). Each finding discloses which evidence types support it, so reviewers can assess confidence independently.
3. Risk Detection Logic
How Securityv0 determines risk when the underlying system already granted permission
This is an important distinction. Traditional identity security asks: "Does this identity have permission to do this?" Securityv0 asks: "Given the full chain of execution authority, what systemic exposure exists?"
The underlying platform (Azure, ServiceNow) validates individual permissions. Securityv0 evaluates the composite exposure created when multiple valid permissions combine into automation chains:
| Risk condition | What it means | Example |
|---|---|---|
| Orphaned automation | An automation runs under an identity whose owner has left the organization or is disabled | A Foundry agent generating invoices, created by a former employee, still executing daily with access to billing APIs |
| Cross-system authority chain | A single identity has execution authority spanning multiple systems, creating a lateral movement path | A ServiceNow integration user that triggers Azure automation which accesses production databases |
| Scope drift | An identity's effective authority has expanded over time beyond its original purpose | A service principal originally created for dev testing now has Reader access across all production subscriptions |
| Unbounded execution scope | An automation can reach sensitive systems or data domains with no governance boundary | An AI agent with connections to both internal HR systems and external LLM APIs — creating a potential data egress path |
| Dormant authority | An identity has standing permissions but shows no recent execution activity | A service principal with Contributor role that hasn't signed in for 180 days — standing authority without active use |
None of these conditions violate individual permission checks. Each permission was granted legitimately. The risk exists in the combination and governance state of the authority chain — which is what Securityv0 surfaces.
No customer-authored rules required. The platform ships with a built-in deterministic evaluation rule set that assesses authority paths against governance conditions (orphaned ownership, unbounded scope, cross-system chains, etc.). Customers do not need to define policies or write rules upfront — the evaluator produces findings from the authority graph immediately upon first scan.
4. Automation Scope
What types of automation are covered
| Category | Platforms | What we discover |
|---|---|---|
| AI Agents | Azure AI Foundry | Agent definitions, tool connections, identity bindings, reachable APIs |
| ITSM Automations | ServiceNow | Flows, scripts, scheduled jobs, REST integrations, outbound API calls |
| Cloud Identity | Microsoft Entra ID, Azure | Service principals, managed identities, role assignments, OAuth grants |
| CI/CD | GitHub (planned) | Workflow definitions, secrets usage, deployment targets, OIDC federation |
| Cloud Automation | AWS (planned) | Lambda functions, Step Functions, EventBridge rules, IAM roles |
Extensibility
Securityv0 uses a canonical data model (NormalizedGraph). Every connector transforms platform-specific data into the same schema: identities, automations, systems, relationships, and authority paths.
Adding a new platform means building a new connector that produces the same canonical output. The evaluation engine, evidence packs, and UI work identically regardless of source platform. This means:
- RPA platforms (UiPath, Power Automate, Automation Anywhere) can be added using the same pattern
- Additional cloud providers (GCP) follow the same cross-account role / federation model
- Custom enterprise platforms can be integrated if they expose identity and automation metadata via API
5. AWS Scope
Status: shipped 2026-05
The AWS connector is in production as of 2026-05. Multi-account scanning via AWS Organizations + CloudFormation StackSets is supported. The full read-only IAM permission set is enumerated in the canonical CloudFormation template at sv0-connectors/integrations/aws/cfn/securityv0-readonly-role.yaml. For a plain-English customer-facing summary suitable for sharing with a CISO or AWS engineer, see the AWS Access — Customer Summary.
What the connector extracts today (shipped 2026-05)
A. AI agent environments (equivalent to Azure Foundry):
- Amazon Bedrock agents, agent versions, action groups, knowledge bases, flows, and guardrails
B. General cloud automation:
- Lambda functions and their execution roles, function URLs, event source mappings
- Step Functions state machines and execution metadata
- EventBridge rules, targets, event buses, connections, and API destinations
- ECS clusters, services, and task definitions
- SNS topics (attributes and tags)
- IAM users, roles, groups, policies, federation providers (OIDC/SAML), and cross-account trust relationships
C. Container image metadata:
- ECR repository policies, lifecycle policies, and image manifests
D. Data store and credential metadata:
- S3 bucket settings (location, policy, encryption, public-access-block, logging) — settings only, never bucket contents (default mode)
- DynamoDB table descriptions
- Secrets Manager secret names and resource policies — names only, never secret values
- SSM Parameter Store parameter names — names only, never parameter values
E. Audit and compliance signal:
- CloudTrail trail configuration and event metadata (via
cloudtrail:LookupEvents) - AWS Organizations account list, OU structure with full upward traversal (
ListParents+DescribeOrganizationalUnit), and SCPs (org-mode only)
F. Optional — CloudTrail S3 archive (opt-in via CFN parameter):
When a customer needs execution evidence beyond the ~90-day cloudtrail:LookupEvents API window, they can opt in by setting the CloudTrailBucketArn parameter on the canonical CFN template. The role then gains a second managed policy granting s3:ListBucket and s3:GetObject scoped to the named CloudTrail bucket only — no other S3 bucket is readable. Default deployments leave the parameter empty and the second policy is never created.
On the integration roadmap (granted by canonical CFN, not yet extracted)
The canonical CFN grants permissions for the full integration roadmap. The following categories are reserved for upcoming connector features and are not yet extracted by the current connector build:
- IAM Identity Center (AWS SSO) instances, permission sets, account assignments
- EKS Pod Identity associations
- KMS key policies and aliases
- AWS Config rules and compliance state
- Access Analyzer findings
We will not silently begin extracting these without notifying connected customers.
Authentication and deployment
Authentication: Cross-account IAM role (AssumeRole) with least-privilege read-only policy and a customer-set ExternalId on the trust. Standard AWS pattern for third-party security tools (same as Wiz, Orca, Datadog Cloud Security, Prisma Cloud).
Multi-account / org-mode: Supported. The connector enumerates accounts via AWS Organizations (when an org-discovery role is provided) or via an explicit account list. Per-account assume-role uses uniform SecurityV0ReadOnly naming and CloudFormation StackSets for deployment. See AWS Org-Mode Bootstrap.
Architecture note: AWS follows the same Extract → Transform → Diff → Load pattern as Azure and ServiceNow, producing the same canonical data model. The same evaluator rules, evidence packs, and UI handle AWS findings without modification.
6. Proposed Next Steps
-
Technical deep dive session — Walk through connector architecture, live discovery flow, and evidence chain reconstruction with Inetum engineering
-
Authentication method selection — Based on this document, Inetum selects preferred auth methods for their environments (and their customers' environments). We configure accordingly.
-
Internal sandbox test — Deploy Securityv0 in an Inetum Azure sandbox with Entra ID + ServiceNow integration. Initial setup uses client secret (Entra) and basic auth (ServiceNow) — both available today. Certificate-based auth can be configured once available if required for production. Setup time: 15-30 minutes. First results: 24-48 hours.
-
Assessment review — After the 14-day evaluation sprint, review findings together. The assessment produces: execution authority paths, risk exposures, ownership gaps, and recommended risk reducers — all with full evidence chains.
This document is a draft and may be revised following third-party review of our authentication integration approaches. We are happy to schedule a follow-up call to discuss any of these topics in detail.
Contact: contact@securityv0.com