agentdiscover 2.7.2__tar.gz → 2.7.4__tar.gz

{agentdiscover-2.7.2 → agentdiscover-2.7.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: agentdiscover
-Version: 2.7.2
+Version: 2.7.4
 Summary: Discover every AI agent in your infrastructure. 5-layer detection: static analysis, network monitoring, eBPF/Kubernetes runtime, endpoint, and cloud audit (CloudTrail). Company-level correlation. AIBOM export. MCP server detection.
 Project-URL: Homepage, https://defendai.ai
 Project-URL: Documentation, https://github.com/Defend-AI-Tech-Inc/agent-discover-scanner/blob/main/README.md
@@ -138,6 +138,41 @@ crewai-agent (CONFIRMED)
 
 ---
 
+## What counts as an "agent"
+
+DefendAI classifies **AI-capable components**, not just top-level orchestrators. Any component that invokes a model, holds a memory buffer, binds a tool, or queries a vector store is an independently governable unit — it can exfiltrate data, consume budget, or behave unexpectedly on its own.
+
+This matters because the gap between "we have one AI agent" (what the team believes) and the actual component count is routinely 5–15×.
+
+**Example — a single LangGraph application with 3 workers:**
+
+| # | Component | Why it's tracked |
+|---|---|---|
+| 1 | `StateGraph` | Graph entrypoint; controls execution flow |
+| 2–4 | Worker agent nodes ×3 | Each is an independent LangChain agent |
+| 5–7 | LLM bindings ×3 (one per worker) | Direct model invocations; each has its own token budget |
+| 8 | Supervisor node | Routes tasks between workers; has its own LLM call |
+| 9 | LLM binding for supervisor | Additional model invocation with separate prompt |
+| 10 | Tool node | Executes tool calls on behalf of workers |
+| 11 | Vector store retriever | RAG component; queries an external embedding store |
+| 12 | Memory checkpointer | Persists conversation state across turns |
+| 13 | Prompt templates | Carry system-level instructions that can be injected or drifted |
+| 14 | Output parser | Transforms model output; can silently drop or alter content |
+| 15 | Human-in-the-loop interrupt | Pause point that can be bypassed in non-interactive runs |
+
+One application. One developer who says "it's just an AI assistant." Fifteen components that each independently touch a model, a store, or a tool — any of which could be ungoverned, GHOST-classified, or carrying a stale permission scope.
+
+**Why component-level visibility matters:**
+
+- A worker's LLM binding can be swapped (model drift) without changing the agent node that wraps it.
+- A retriever can be pointed at a new vector store index without redeploying the application.
+- A prompt template lives in a config file, not code — static analysis misses it; only runtime observation catches the change.
+- GHOST detection fires at the component level: if worker 2's LLM binding starts calling a different endpoint, the graph-level agent still looks CONFIRMED while that specific binding is GHOST.
+
+agentdiscover reports each component as a separate inventory item so your governance controls can target the right granularity.
+
+---
+
 ## Quick start
 
 ```bash

{agentdiscover-2.7.2 → agentdiscover-2.7.4}/README.md

@@ -95,6 +95,41 @@ crewai-agent (CONFIRMED)
 
 ---
 
+## What counts as an "agent"
+
+DefendAI classifies **AI-capable components**, not just top-level orchestrators. Any component that invokes a model, holds a memory buffer, binds a tool, or queries a vector store is an independently governable unit — it can exfiltrate data, consume budget, or behave unexpectedly on its own.
+
+This matters because the gap between "we have one AI agent" (what the team believes) and the actual component count is routinely 5–15×.
+
+**Example — a single LangGraph application with 3 workers:**
+
+| # | Component | Why it's tracked |
+|---|---|---|
+| 1 | `StateGraph` | Graph entrypoint; controls execution flow |
+| 2–4 | Worker agent nodes ×3 | Each is an independent LangChain agent |
+| 5–7 | LLM bindings ×3 (one per worker) | Direct model invocations; each has its own token budget |
+| 8 | Supervisor node | Routes tasks between workers; has its own LLM call |
+| 9 | LLM binding for supervisor | Additional model invocation with separate prompt |
+| 10 | Tool node | Executes tool calls on behalf of workers |
+| 11 | Vector store retriever | RAG component; queries an external embedding store |
+| 12 | Memory checkpointer | Persists conversation state across turns |
+| 13 | Prompt templates | Carry system-level instructions that can be injected or drifted |
+| 14 | Output parser | Transforms model output; can silently drop or alter content |
+| 15 | Human-in-the-loop interrupt | Pause point that can be bypassed in non-interactive runs |
+
+One application. One developer who says "it's just an AI assistant." Fifteen components that each independently touch a model, a store, or a tool — any of which could be ungoverned, GHOST-classified, or carrying a stale permission scope.
+
+**Why component-level visibility matters:**
+
+- A worker's LLM binding can be swapped (model drift) without changing the agent node that wraps it.
+- A retriever can be pointed at a new vector store index without redeploying the application.
+- A prompt template lives in a config file, not code — static analysis misses it; only runtime observation catches the change.
+- GHOST detection fires at the component level: if worker 2's LLM binding starts calling a different endpoint, the graph-level agent still looks CONFIRMED while that specific binding is GHOST.
+
+agentdiscover reports each component as a separate inventory item so your governance controls can target the right granularity.
+
+---
+
 ## Quick start
 
 ```bash

{agentdiscover-2.7.2 → agentdiscover-2.7.4}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "agentdiscover"
-version = "2.7.2"
+version = "2.7.4"
 description = "Discover every AI agent in your infrastructure. 5-layer detection: static analysis, network monitoring, eBPF/Kubernetes runtime, endpoint, and cloud audit (CloudTrail). Company-level correlation. AIBOM export. MCP server detection."
 readme = "README.md"
 requires-python = ">=3.10"

{agentdiscover-2.7.2 → agentdiscover-2.7.4}/src/agent_discover_scanner/aibom.py

@@ -69,7 +69,7 @@ def generate_aibom(inventory_json: Path, output_path: Path) -> dict[str, Any]:
             "tools": [
                 {
                     "vendor": "DefendAI",
-                    "name": "AgentDiscover Scanner",
+                    "name": "AgentDiscover",
                     "version": scanner_version,
                     "externalReferences": [
                         {

{agentdiscover-2.7.2 → agentdiscover-2.7.4}/src/agent_discover_scanner/cli.py

@@ -39,7 +39,7 @@ import socket
 __version__ = _pkg_version("agentdiscover")
 logger = logging.getLogger(__name__)
 
-app = typer.Typer(help="AgentDiscover Scanner: Detect Autonomous AI Agents and Shadow AI")
+app = typer.Typer(help="AgentDiscover: Detect Autonomous AI Agents and Shadow AI")
 console = Console()
 
 
@@ -49,7 +49,7 @@ def version_callback(value: Optional[bool]) -> None:
     """
     if not value:
         return
-    console.print(f"AgentDiscover Scanner v{__version__}")
+    console.print(f"AgentDiscover v{__version__}")
     raise typer.Exit()
 
 

{agentdiscover-2.7.2 → agentdiscover-2.7.4}/src/agent_discover_scanner/exporters/mcpfw_policy.py

@@ -1,5 +1,5 @@
 """
-Convert AgentDiscover Scanner MCP findings into a runnable mcpfw policy dict.
+Convert AgentDiscover MCP findings into a runnable mcpfw policy dict.
 
 Entry point: export_mcpfw_policy(scan_result, stance) -> dict
 The returned dict serializes directly to valid mcpfw YAML.

{agentdiscover-2.7.2 → agentdiscover-2.7.4}/src/agent_discover_scanner/sarif_output.py

@@ -13,7 +13,7 @@ from agent_discover_scanner.visitor import Finding
 class SARIFGenerator:
     """Generate SARIF 2.1.0 compliant output."""
 
-    TOOL_NAME = "AgentDiscover Scanner"
+    TOOL_NAME = "AgentDiscover"
     TOOL_VERSION = "1.0.0"
     TOOL_URI = "https://defendai.ai/agentdiscover"