C5 Inventory Item Data Models

Entity definitions for the AI agent visibility platform. All items are discovered by Qpoint at runtime — no agent SDK instrumentation required. Primary observation point is the TLS-terminating network proxy, supplemented by process/system-level observation where noted.

Entity Map

Endpoint (compute host)
  └── User (OS identity)
        └── Session (bounded unit of work)
              ├── Agent (software identity — Claude Code, Cursor, etc.)
              ├── Model (LLM model + provider)
              ├── API Key (credential used)
              ├── MCP Server (MCP server connected during session)
              ├── Agent Capability (tools + skills available to session)
              ├── File (files read/written by tools)
              ├── Subagent (child session spawned by this session)
              ├── Secondary Call (non-LLM HTTP call made by a tool)
              └── LLM Turn ─ session-detail only
                    └── Tool Call (unified builtin + MCP invocations)

Inventory Items

Ten top-level items that form the navigable inventory:

Two additional entities are session-detail only — they appear in session drill-downs but are not top-level inventory items:

1. Session

What it is: The primary unit of observation. A bounded autonomous work episode — from first API call to process exit or sustained inactivity. Everything else is a tag on a session.

Identifier: session_id — from Claude Code's session.id attribute (proxy-visible); for other agents, a Qpoint-assigned UUID derived from source PID + first-call timestamp.

Fields

Relationships

• Has many LLM Turns
• Has many Tool Calls (through turns)
• Has many Files accessed
• Has many Secondary Calls
• Has one Agent
• Has one User
• Has one Endpoint
• Has one API Key
• May have one parent Session (if subagent)
• May have many child Subagent sessions

2. Agent

What it is: The software system running the session — an autonomous AI runtime (e.g. Claude Code, Cursor, a LangChain pipeline). Identified by User-Agent string and Stainless SDK headers. An agent is not a session — one agent (e.g. "Claude Code v1.2.0") can have thousands of sessions across many users.

Identifier: agent_id — derived from user_agent + stainless_package_version (normalized slug, e.g. claude-code@1.2.0).

Fields

Relationships

• Has many Sessions
• Used by many Users

3. User

What it is: The human identity behind a session. May be an authenticated developer (email from Claude Code session metadata), an OS user (from process uid), or an application service account.

Identifier: user_id — user.email from Claude Code metadata when available; otherwise <endpoint_id>:<uid> (OS user on host).

Fields

Relationships

• Has many Sessions
• Runs on many Endpoints
• Uses many Agents

4. Model

What it is: A specific LLM model invoked by an agent, including the provider that serves it. Identified by the model field in API requests and responses — the response model is authoritative (it reflects actual routing, not just the requested model). Provider context (hostname, base URL) is a property of the model rather than a separate entity.

Identifier: model_id — the canonical model string from the API response, e.g. claude-opus-4-6, claude-sonnet-4-6, gpt-4o.

Fields

Relationships

• Used in many Sessions and LLM Turns

5. API Key

What it is: The Anthropic API credential used to authenticate sessions. A key is visible at the proxy layer (x-api-key header). Different keys may correspond to different organizational units, cost centers, or environments. Keys are stored as hashed tokens — only the first/last N chars shown in the UI.

Identifier: api_key_id — SHA-256 hash of the raw key value (never stored in plaintext).

Fields

Relationships

• Used by many Sessions
• May be associated with one User or many (shared org key)

6. Endpoint

What it is: The compute environment where an agent session ran — a laptop, cloud VM, CI runner, or container. The physical or virtual host. Identified by a combination of source IP and system metadata.

Identifier: endpoint_id — stable host identifier derived from: hostname (from process metadata) or source IP (from proxy), preferring hostname when available.

Fields

Relationships

• Hosts many Sessions
• Used by many Users
• Contains many Files accessed

7. MCP Server

What it is: A Model Context Protocol server that an agent connected to during a session. Provides tools, resources, or prompts to the agent. Identified from the MCP initialize exchange (serverInfo.name + serverInfo.version). Note: stdio-transport MCP servers are opaque at the proxy layer — observable only with process/eBPF instrumentation.

Identifier: mcp_server_id — <server_name>@<server_version> (e.g. filesystem@1.0.0, github@0.6.2).

Fields

Relationships

• Connected to during many Sessions
• Exposes many Agent Capabilities (tools)
• Has many Tool Calls (invocation records)

8. Agent Capability

What it is: A capability available to an agent during a session — either a tool (callable function from the API tools[] array or an MCP server) or a skill (named instruction file loaded into the system prompt). Both describe what an agent can do in a session and share an inventory view, differentiated by capability_type.

Identifier: capability_id — <type>:<source>:<name> (e.g. tool:builtin:bash, tool:filesystem:read_file, skill:claude-code:wireframe-builder).

Shared Fields

Tool-Specific Fields (capability_type = tool)

Skill-Specific Fields (capability_type = skill)

Relationships

• Referenced in many Sessions
• Tools: may belong to one MCP Server (if MCP-sourced)
• Tools: has many Tool Calls (invocation events)

9. File

What it is: A file on the host file system that was read or written by an agent tool during a session. Identified by absolute path. Multiple sessions may access the same file; each access is a distinct event.

Identifier: file_id — <endpoint_id>:<absolute_path> (file identity scoped to the host where it exists).

Fields

File Access Event (join entity: Session ↔ File)

Relationships

• Accessed during many Sessions
• Via many Tool Calls
• Exists on one Endpoint

10. Secondary Call

What it is: An outbound HTTP/HTTPS request made by a tool (not the LLM itself) — e.g. web_fetch fetching a URL, bash running curl github.com, or computer_use loading a web page. Represents the "hidden exposure" surface: indirect network access attributable to an agent session.

Identifier: secondary_call_id — Qpoint-assigned UUID.

Fields

Relationships

• Attributed to one Session
• Triggered by one Tool Call (when correlatable)

11. LLM Turn (session-detail only)

What it is: A single request/response pair with the LLM API — one call to POST /v1/messages. The atomic unit of LLM interaction. A session is composed of many turns. Displayed in session drill-downs; not a top-level inventory item.

Identifier: turn_id — Anthropic's response id field (e.g. msg_01XFDUDYJgAACzvnptvVoYEL).

Fields

Relationships

• Belongs to one Session
• Uses one Model
• Has many Tool Calls

12. Tool Call (session-detail only)

What it is: A single tool execution — either a built-in tool (tool_use/tool_result pair in the Anthropic API) or an MCP tools/call invocation. Both represent the same semantic event: a tool was invoked and produced a result. Unified under one entity with call_type indicating the protocol. Displayed in session drill-downs; not a top-level inventory item.

Identifier: tool_call_id — the tool_use_id for builtin calls (e.g. toulu_01A09q90...); derived from JSON-RPC id + MCP server ID + timestamp for MCP calls.

Fields

Relationships

• Belongs to one Session and one LLM Turn (when call_type = builtin)
• References one Agent Capability
• May belong to one MCP Server (when call_type = mcp)
• May produce File access events (if file-touching tool)
• May produce Secondary Calls (if network-touching tool)

Observation Mechanism Summary