Agentless collection
A single-binary collector runs through existing remote-management channels—WinRM on Windows and SSH on Linux—and is removed after the assessment. No persistent endpoint agent, kernel driver, or always-on daemon is required.
TECHNICAL CAPABILITIES
How AISpy turns
AI exposure
into evidence.
For security engineers, architects, and technical evaluators: what AISpy detects, how it illuminates exposure, and how the evidence contributes to risk.
Request a technical walkthrough01ARCHITECTURE
AISpy inspects locally and exports only metadata through an assessment deployed in your environment.
Collect at the endpoint.
Analyze in your environment.
On-premise deployment
A containerized platform brings together the web application, task workers, queue, database, and TLS termination in the customer’s environment. Signed offline collection and export support disconnected assessment workflows.
Content-private inspection
The collector reads relevant content locally to make a determination, then exports structured metadata such as findings, hashes, paths, counts, and timestamps. Raw content stays on the endpoint.
Protected collection channels
TLS protects the web UI and collector communications, with integrity checks for collector delivery and results. Windows and Linux collectors share the risk-scoring engine while handling their own operating-system artifacts.
Platform coverage: Windows and Linux today. macOS agents are in development. Collection coverage depends on permissions, endpoint access, and available artifacts.
02DISCOVERY
Collection covers AI artifacts, connections, automation, and exposure, with platform and permission limits recorded.
Examine the AI surface behind the application.
Modern AI exposure lives in models, configuration, permissions, connected tools, and automation. AISpy brings those layers into the assessment.
AI applications, runtimes & models
Detect host applications such as Claude Desktop, Cursor, Cline, Windsurf, Continue, Aider, Codex, and Claude Code. Inspect their configuration alongside installation evidence. For local runtimes such as Ollama, LM Studio, llama.cpp, and Jan, examine processes, listening ports, model artifacts, capability indicators, and available model-run history.
Distinguish an installed model from evidence of it being loaded, and a loopback listener from a network-exposed service.
Cloud AI usage & account context
Examine configured AI endpoints, API-key indicators, and signed-in service evidence in supported browser profiles for services such as ChatGPT, Claude, Gemini, and Copilot. Personal-versus-corporate account context helps teams evaluate use against organizational policy.
An account determination depends on available identity evidence. A connection or configured URL alone does not establish that a file was transferred.
MCP servers & connected tools
Parse supported host-app MCP configurations for local stdio servers and remote URL, SSE, or HTTP transports. Surface declared shell, filesystem, database, or browser capabilities, configured filesystem scope, and remote endpoints.
Review the trust and exposure created by a connected tool even when no conventional application installation is present.
Hooks, skills, plugins & permission posture
Inspect shell-executing hooks, skill bundles, host plugins, and editor extensions. Hash relevant artifacts to support change detection. Read settings such as auto-approve, bypass-permissions, or YOLO mode that remove a human approval gate.
Permission bypass combined with shell-capable automation creates a materially different exposure from an installed assistant alone.
Autonomous agents & persistence
Surface frameworks such as CrewAI, LangGraph, and AutoGen, and AI-related startup mechanisms such as Run keys, scheduled tasks, systemd units, and cron. When a startup command references a script, inspect it locally for AI-framework imports and AI-API calls.
A generic command such as python /opt/run.py can still represent persistent AI automation; the command name is only part of the evidence.
Credentials & data proximity
Look for AI API-key and secret indicators in supported configurations, environment variables, committed files, and notebooks, with provider attribution where available. Examine sensitive-data proximity and AI-referenced resources as part of the exposure picture.
A sensitive file near AI is an exposure indicator. Evidence of actual access or transfer requires a stronger observation.
The collection surface, category by category.
Coverage varies by platform, access, and available artifacts. Windows-specific sources apply to Windows; Linux uses its native service, scheduling, shell, and runtime artifacts. No row alone earns observed_transfer or verified_permission. Inspect the evidence and coverage record for the actual result.
| Category | What is collected | Highest evidence label it can earn |
|---|---|---|
| AI apps & configurationsAI applications & CLIs | Installation artifacts, version, path, and owner context. | installed |
| AI apps & configurationsHost application configuration | Configured models, API endpoints, and referenced resources. | configured |
| AI apps & configurationsAI packages & SDKs | Python and Node package metadata and AI-framework imports. | installed |
| Runtimes & listenersActive AI runtimes | Process, command line, owner, and runtime activity observations. | observed_execution |
| Runtimes & listenersListening services | Bind address, port, owning process, and loopback or network scope. | observed_execution |
| Model files & historyLocal model inventory | Model path, format, size, hash, and available runtime metadata. | installed |
| Model files & historyModel capability classification | Code, vision, context length, parameters, and uncensored-class indicators. | installed |
| Model files & historyModel-run history | Runtime log records of model loads, counts, and last-seen times. | observed_execution |
| Model files & historyPickle opcode analysis | Static opcode and callable inspection; flagged symbols and scan limitations. | installed |
| Model files & historyModel provenance | Hash, claimed metadata, format consistency, and provenance mismatches. | installed |
| MCP connectionsLocal MCP servers | Configured stdio commands, arguments, and local server references. | configured |
| MCP connectionsRemote MCP servers | Remote URL, HTTP or SSE transport, and endpoint configuration. | configured |
| MCP connectionsMCP capabilities | Declared shell, filesystem, database, and browser tool capabilities. | configured |
| MCP connectionsMCP resource scope | Configured filesystem roots and resource boundaries. | configured |
| Hooks, skills & permissionsShell-executing hooks | Hook triggers, command references, and artifact hashes. | configured |
| Hooks, skills & permissionsSkill bundles | Skill artifacts, hashes, and declared or referenced capabilities. | configured |
| Hooks, skills & permissionsPlugins & editor extensions | Host plugins, VS Code and JetBrains extension metadata and configuration. | configured |
| Hooks, skills & permissionsPermission posture | Auto-approve, bypass-permissions, and YOLO configuration flags. | configured |
| Agent frameworksAutonomous AI frameworks | CrewAI, LangGraph, AutoGen, and related package or script indicators. | installed |
| PersistenceWindows Run keys & startup | AI-related startup entries, command lines, and referenced paths. | configured |
| PersistenceWindows scheduled tasks | AI-related task actions, trigger metadata, and script references. | configured |
| PersistenceLinux systemd units | AI-related service definitions, commands, and startup settings. | configured |
| PersistenceLinux cron jobs | AI-related scheduled commands and referenced script paths. | configured |
| PersistenceStartup-script inspection | Locally inspected AI imports and API calls behind generic commands. | configured |
| CredentialsConfiguration-file credentials | Provider and location of key indicators; fingerprints, not secret values. | installed |
| CredentialsEnvironment credentials | AI credential indicators in environment variables and .env artifacts. | installed |
| CredentialsRepository & notebook credentials | Secret indicators in committed files and notebook cells. | installed |
| Browser AIAI browser extensions | Extension IDs, permissions, host scopes, and AI-related indicators. | configured |
| Browser AIAI service history | Supported browser records, service attribution, counts, and timestamps. | observed_access |
| Browser AISigned-in AI sessions | Service and account context where supported identity evidence exists. | configured |
| Data & conversation storesSensitive-data proximity | Local inspection results and proximity metadata; no inferred transfer. | installed |
| Data & conversation storesAI-referenced resources | Configured RAG ingestion targets and referenced data locations. | configured |
| Data & conversation storesConversation-store metadata | Store paths, size, item counts, owner, and activity timestamps. | installed |
| Network indicatorsAI DNS indicators | Resolved AI service domains and counts; resolution alone is not contact. | configured |
| Network indicatorsAI API connections | Observed service contacts with endpoint and process context where available. | observed_access |
| Windows artifactsPrefetch | AI-related execution traces and available execution timestamps. | observed_execution |
| Windows artifactsAmCache | Application and file metadata; presence alone does not establish execution. | installed |
| Windows artifactsWindows Recall | Recall feature and local artifact metadata where available. | configured |
| Windows artifactsCredential Manager | AI-related credential entry metadata without exporting secret values. | installed |
| Windows artifactsCloud sync | Configured sync locations and AI-related artifacts in those locations. | configured |
| Windows artifactsWSL | Distribution context and accessible AI tooling or package indicators. | installed |
| Shell artifactsPowerShell history | AI-related command references in supported history artifacts. | configured |
| Linux artifactsLinux shell & runtime records | AI-related shell history and runtime records; execution requires corroborating logs. | observed_execution |
03MALICIOUS & UNSAFE MODEL ANALYSIS
Static model inspection surfaces dangerous callable patterns without executing the model.
Inspect the model
before it executes.
Pickle opcode analysis
Statically walk supported pickle bytecode without calling pickle.load or executing the model. Inspect REDUCE and GLOBAL in context, including callables such as os.system and subprocess. Surface serialized code in supported Keras Lambda layers, as shown in the supplied model-scan example. Record flagged symbols, parsing limits, and the scan verdict.
Serialization safety
Distinguish code-capable pickle-based serialization from tensor-oriented formats such as safetensors and GGUF. An unsafe format is a risk signal; a dangerous callable sequence supplies stronger evidence. A format label is not a blanket safety guarantee.
Provenance & known-good hashes
Compare hashes and available metadata with claimed format and provenance. A missing or mismatched origin prompts review. The known-good hash allowlist adds trust context, is off by default, and does not erase independent behavioral findings.
Model capability classification
Identify available indicators for uncensored or abliterated models, vision, code, and long-context capabilities, alongside parameters and quantization. Classification depends on the model metadata and supporting evidence.
Inspection identifies suspicious artifacts and supported payload patterns. It does not claim universal malware detection. Model-load evidence does not by itself prove a flagged callable executed.
04DETECTION SCENARIOS AT DEPTH
Related findings explain an exposure scenario more clearly than an application name alone.
Read the relationship
between the findings.
Malicious AI
Correlate static pickle findings, flagged callables, and provenance. Add model-run evidence where available to distinguish an artifact on disk from a model that was loaded.
Shadow autonomous agents
Follow a scheduled task or startup command into its referenced script. Framework imports and AI-API calls expose persistent automation behind a generic Python command.
Unrestrained AI
Combine bypass-permissions with shell-capable hooks or skills. The Unrestrained Agent scenario has a nominal ×1.45 multiplier; evidence confidence informs the applied contribution. Sanctioning the host application does not sanction the dangerous combination.
Uncensored & unvetted models
Join a model’s identity, hash, and capability class to supported runtime history. Available load counts and timestamps distinguish an installed artifact from recorded use.
Leaked credentials
Attribute credential indicators to providers and locations. Correlate fingerprints across endpoints without exporting secret values. A key and an autonomous agent on one host warrant a reachability and scope investigation.
Exposed & over-scoped AI
Examine network-facing bind addresses, broad MCP filesystem roots, and personal-versus-corporate account context. A bind address does not prove firewall reachability, and configured scope does not establish actual data access.
05AIRES RISK SCORING
AIRES connects the endpoint score to its findings, confidence, and recommended actions.
A score you can explain.
AIRES produces a 0–100 endpoint score across capability, egress, data exposure, credentials, and governance. Network reach and data proximity inform the exposure assessment. Findings retain confidence and freshness; related exposures contribute through scenario mechanics.
Sanctioning can lower presence weight. Independently evidenced credentials, permission bypass, shell hooks, and malicious models retain their risk contributions. AIRES is a prioritization model, not a breach probability.
Explore the full AIRES scoring model06EVIDENCE LABELS
Every label states what the observation establishes and what it cannot establish.
Say what the evidence establishes.
Evidence labels distinguish configuration from observed activity and verified authorization. Stronger labels require stronger evidence; they are never earned by implication.
installed- An artifact exists on disk.Does not establish that it was used.
configured- A configuration references a tool, resource, or endpoint.Does not establish execution, reachability, or transfer.
observed_execution- A process was observed running.Does not establish data access.
observed_access- A resource was accessed or a service contacted.Does not by itself establish that data left the endpoint.
observed_transfer- Evidence establishes that data was transferred.Requires direct support; configuration and connections are insufficient.
verified_permission- Authorization was confirmed through an authoritative source.Configuration inference alone cannot earn this label.
unknown / stale- The state is indeterminate or the observation is no longer fresh.An unverified surface must not appear clean.
THE FINDING’S EVIDENCE CHAIN
Endpoint User Category Path First / last seen Observation count
Finding details retain collection context and what remains unverified. A configured attack path is a possible exposure path; it is not automatically proof that the path was used.
07GOVERNANCE & SCOPED APPROVALS
Administrators define approved use; assessments expose divergence without suppressing independent risk.
Define the approved state.
Surface divergence from it.
Scoped approvals
Define a kind and match, host group, owner, business purpose, expiry, permitted capabilities, and residual risk treatment. An in-scope approval acknowledges legitimate use while preserving the underlying evidence.
- Host-group boundaries keep approvals scoped.
- Capability divergence restores full severity.
- Independent credential and behavioral risks remain visible.
- Expiry brings the risk back into review.
AI Maturity Scorecard
An organizational view evaluates visibility, credential hygiene, data separation, policy compliance, local-model control, browser-extension risk, and shadow-AI control.
A fleet with an unsanctioned autonomous agent is capped rather than receiving an “Optimized” grade based on unrelated controls. A strong aggregate score should not conceal an unresolved governance gap.
Assessment-based oversight: scheduled and on-demand scans check the approved baseline. This is not a claim of continuous real-time enforcement.
08VERIFIED CLOSURE
A fix earns verification only when a covered rescan supports closure.
Verify the change.
Keep the attestation.
After a change, an analyst requests verification. A subsequent scan must cover the finding’s category and establish that the exposure is gone before AISpy records a verified fix.
The scanner no longer observes it.
The relevant category was covered and the exposure is absent. This state alone carries no verification attestation.
A business decision with an expiry.
An explicit acceptance acknowledges residual risk. When that acceptance expires, the risk returns to the score.
A covered rescan supports closure.
The verification path records the before and after, requesting actor, ticket reference, and policy version. This state is not set through a manual dropdown.
The checks behind verified closure
- An offline endpoint or failed detector leaves the exposure unverified; it does not establish a fix.
- A rescan that still sees the exposure reopens it with a verification-failed result.
- Credential revocation needs provider-side confirmation. A deleted key file cannot attest to revocation.
- Reappearing exposure reopens a previously verified finding.
Lifecycle events can flow to Jira, ServiceNow, or webhook targets through a durable outbox with retries and visible delivery failures.
09REPORTING & EXPORTS
Reports, workbooks, and machine-readable exports take the evidence to the people who need it.
One assessment.
The outputs your team needs.
Managerial PDF
Fleet AI usage, sanctioned and shadow totals, highest-risk endpoints, AI Maturity Scorecard, and prioritized fixes for leadership.
Technical PDF + XLSX
Per-endpoint findings, evidence chains, labels, coverage limits, and remediation worklists in a detailed report and workbook.
CycloneDX AI-BOM
Models with available hashes and provenance, frameworks, agents, and MCP servers in a standards-based AI bill of materials.
Change digests & correlation
Compare scans to surface changed exposure. Correlate shared credential fingerprints across endpoints; exports use fingerprints, never credential values.
Data gravity
Show what AI can already reach on an endpoint through configured resources and supported access evidence. Distinguish potential reach from observed use.
SIEM & ticket delivery
Send SIEM output and lifecycle events through a durable retrying outbox. Ticket webhooks connect evidence to Jira, ServiceNow, or supported webhook targets with visible delivery failures.
Portal & closure records
Use the fleet dashboard, per-endpoint drill-down, and verified closure records to move from a fleet summary to the evidence behind a finding.
AISpy supports evidence collection for governance, audit, and insurance reviews; it does not certify compliance.
SAMPLE / ILLUSTRATIVE DATA · DEV-12
See a real report.
The deliverables leadership actually reads — and the evidence engineers can audit.
10ENTERPRISE OPERATIONS
Tenant boundaries, roles, scheduling, and offline collection support operational assessments.
Fit AI assessments into the way your team works.
Tenant and role controls
Multi-tenant operation supports separate client environments, role-based access, and audit logging for consultancies and internal teams.
Scheduled and on-demand assessments
Work across host lists and IP ranges, with scan progress and reachable, unreachable, and pending endpoint accounting.
Coverage and delivery visibility
Track detector categories that actually ran. Route SIEM and ticketing events through a retrying outbox so delivery failures remain visible.
Offline collection
Signed offline collection and export provide an assessment path for disconnected, regulated, and OT-adjacent environments.
11DETECTION CONFIDENCE
Known-truth fixtures make detection and scoring assumptions testable in a customer baseline.
Make the assessment
testable against a baseline.
Evaluate clean, sanctioned-AI, and shadow-agent fixtures with known configurations and a repeatable harness. Review detection confidence, missed surfaces, scenario separation, and scoring contributions against that ground truth.
Run the same harness against a customer’s golden image. Results apply to the configurations tested; no general accuracy percentage is asserted. Unreachable endpoints, denied categories, and stale observations retain their limitations.
EVALUATE AISPY IN YOUR CONTEXT