AI Attack Surface Management

JupiterOne AI Attack Surface Management (AI-ASM) gives security and governance teams a single view of the non-human identities (NHIs) in their environment, automatically flags the ones that are AI-related, and shows what each identity can reach across your connected systems.

As teams adopt AI assistants, agents, and platform services, the number of machine identities — service accounts, API keys, OAuth apps, bots, and roles — grows far faster than the human identities security teams traditionally track. AI-ASM brings these identities into the JupiterOne graph, classifies which ones are AI-powered, and governs them against the same control framework model used by Continuous Control Monitoring.

Overview

AI Attack Surface Management enables your team to:

• Discover every non-human identity across your integrated cloud platforms, SaaS tools, and source control, without manual inventory work
• Identify AI identities automatically using detection heuristics that flag NHIs associated with AI agents, models, and AI-powered workloads
• See what each identity can reach — the data stores, repositories, databases, packages, vaults, tables, and disks an identity has access to
• Prioritise by risk so the identities with the broadest reach and the most failing controls surface first
• Govern AI usage against an out-of-the-box NHI governance framework mapped to standards such as NIST AI RMF, the EU AI Act, NIS2, and DORA
• Find shadow AI — AI-powered identities provisioned outside approved channels

Data model

AI-ASM is built on the non-human identity (NHI) — any digital identity that is not a person, such as a service account, machine credential, secret, OAuth app, bot, certificate, API key, webhook, or CI/CD identity. NHIs are discovered through your existing JupiterOne integrations and stored as entities in the graph, so they participate in queries, controls, and relationships like any other asset.

Each NHI carries a set of properties that AI-ASM uses to classify and govern it:

Property	Description
nhiType	The category of identity — for example service_account, secret, oauth_app, bot, service_role, service_linked_role, or credential
isAi	Whether the identity is associated with an AI agent, model, or AI-powered workload
aiConfidence	Confidence that the identity is AI-related: confirmed (signed evidence), or high, medium, or low (heuristic strength)
aiPlatform	The AI platform or vendor the identity belongs to — for example Anthropic, OpenAI, AWS Bedrock, or AWS SageMaker
owner	The human or team accountable for the identity
nhiOwnerStatus	Ownership state used by governance triage: assigned, unassigned, or orphaned

Because NHIs are first-class graph entities, you can query them directly in J1QL:

FIND NHI WITH isAi = true AND aiConfidence = ('confirmed' OR 'high')

note

aiConfidence is a string value (confirmed, high, medium, or low), not a number. Compare it against those literal values rather than a numeric threshold.

How AI-ASM detects AI identities

AI-ASM evaluates every discovered NHI against a set of detection heuristics and records the result on the identity. Each AI identity shows both a confidence level and the detection method that matched, so you can see why an identity was classified as AI-related.

Detection methods include matches on naming conventions and metadata, such as:

• Bot and app names — a Slack bot or app whose name maps to a known AI assistant
• API key names — a secret named for an AI provider, such as an OpenAI or Anthropic API key
• Service account and role patterns — cloud roles created for AI platform services, such as AWS SageMaker or AWS Bedrock execution roles
• Display name patterns — identities whose display names indicate an AI integration

Identities are also grouped into a category that describes the kind of AI usage — for example a Foundation model provider or an AI SaaS application.

The AI-ASM dashboard

The Dashboard is the landing view for AI-ASM. It summarises your AI attack surface and highlights where attention is needed.

Summary metrics across the top show:

• Total NHIs — every non-human identity discovered in your environment
• AI NHIs — the subset classified as AI-related
• Frameworks — the number of frameworks with at least one failing control on an AI identity
• Controls — the number of failing controls
• Reaching data — the number of AI identities that can reach data
• Reachable assets — the total number of assets those identities can reach

Below the metrics, the dashboard breaks the surface down into focused panels:

• Frameworks at risk — frameworks with at least one failing control on an AI identity, so you can see which compliance obligations your AI usage affects
• Failing controls — failing controls grouped and ordered by priority
• AI platforms — a breakdown of AI identities by platform (for example Anthropic, AWS SageMaker, Foqal Agent, Intercom, OpenAI, AWS Bedrock, and Cursor)
• NHI types — the distribution of identities across NHI categories such as bot, service account, secret, and the various role types

Top risk AI identities

The dashboard ranks AI identities by risk in the Top risk AI identities table. Each row shows the identity, its platform, NHI type, and AI detection confidence and method, followed by a breakdown of what the identity can reach — Stores, Repos, DBs, Pkgs, Vaults, Tables, and Disks — and a Total reach count. Identities with the broadest reach surface at the top, so you can focus on the identities that would cause the most damage if compromised.

Control status

The Control status section at the bottom of the dashboard shows the controls that govern your AI identities. Filter by AI only, framework, priority, or organisational unit to focus the view. Each control card shows the control name and description, its priority, the framework it belongs to, the number of identities affected, and the number of requirements it maps to.

The AI inventory

The Inventory view lists every non-human identity in your environment in a single sortable, filterable table. Use the AI only / Non-AI only filter to switch between your full NHI inventory and just the AI identities, and filter further by type, platform, category, detection confidence, or organisational unit.

Each row shows:

Column	Description
Name	The identity name, with an AI badge when the identity is AI-related
Class and Type	The graph class and entity type (for example aws_iam_role, github_repo_secret, slack_user)
Platform	The AI platform the identity belongs to, where known
NHI type	The identity category (bot, service account, secret, role types, and so on)
Category	The kind of AI usage, such as Foundation or AI SaaS
AI detection	The detection confidence and the method that matched
Owner	The human or team accountable for the identity
Data reach	A link into the graph and a count of reachable assets
Status	The identity's current status
Failing controls	The number of failing controls for the identity

Use Export to download the current view, respecting your active filters.

Inspecting an identity

Select any identity to open its detail panel. The panel includes an AI-generated summary of the identity, its AI context (platform, detection confidence, and detection method), when it was first and last seen, its neighbours in the graph, and its relationships — so you can understand what an identity is, why it was classified as AI, and what it connects to without leaving the view.

Governing AI identities

AI-ASM ships with the AI Attack Surface Management (AI-ASM) — NHI Governance Framework, an out-of-the-box framework that applies the Continuous Control Monitoring model to your non-human and AI identities. Its controls cover common governance obligations, such as:

• Every NHI has an assigned owner — each identity must have a designated human owner accountable for its security posture and lifecycle
• Shadow AI identities are flagged — AI-powered identities provisioned outside approved channels are detected and surfaced
• AI-powered NHIs have a documented purpose — each AI identity must have a documented business justification and approved use case
• Access control policies cover NHIs — non-human identities must be included in access control governance alongside human identities

These controls map to recognised standards and regulations — including NIST AI RMF, the EU AI Act, NIS2, and DORA — so governing your AI identities contributes directly to your compliance posture. Because the controls run on the same engine as the rest of CCM, their results appear in the AI-ASM dashboard, the controls views, and your framework compliance scores.

Getting started

1. Connect the integrations that hold your identities — cloud platforms, SaaS applications, and source control — so JupiterOne can discover your NHIs. AI-ASM uses the integrations you already have configured.
2. Navigate to AI-ASM > Dashboard to see your AI attack surface, the frameworks it affects, and your highest-risk identities.
3. Open AI-ASM > Inventory and filter to AI only to review the AI identities in your environment, their detection confidence, and what they can reach.
4. Assign owners to unowned identities and review the Control status section to address failing governance controls.

Related topics

• Continuous Control Monitoring
• What's new in AI-ASM 1.0
• J1QL query language