ai-agents-reframe.md
ai-agents-reframe.md
Reframing Qpoint around AI agent visibility
AI agents (any application whose brain is an LLM) are now autonomous actors running inside your organization and infrastructure, and they are everywhere. They make API calls, read and write files, invoke local and remote MCP servers, and use all sorts of "tools". These tools have invisible secondary effects (file access/subcommands/network calls/etc). Qpoint is currently built for production apps running on Linux/k8s infra, and tells the story of interconnectivity and data-paths. This high-level proposal shifts the product story around the more urgent problem of AI agents (what is it, where is it running, who launched it, what is it doing, and whether that behavior was safe). This reframing outlines the goals and primitives needed to tell that story well while re-using the technology and design framework where possible.
Goals
- Full visibility into the agent runtime — know every agent running in your org, who ran it, on which machine, using which model and credentials.
- Map the full exposure surface — not just the LLM API call, but the secondary network calls, files touched, and MCP servers. ie: The LLM invokes tools through an agent, but what those tools do are opaque.
- Enable policy and governance — give security teams the primitives to define what's permissible and alert on deviations.
Three Value Pillars
1. Discovery & Inventory
You can't secure what you can't see. Qpoint gives you a live inventory of every AI agent, user, model, MCP server, and tool operating in your environment — automatically, with no SDK instrumentation required.
2. Hidden Risk & Exposure
AI agents don't just call the LLM — they run shell commands, read credentials files, fetch URLs, push to GitHub. Qpoint traces the full chain: the agent session → the tools it used → the secondary network calls those tools made. The exposure surface is often 10× larger than the direct LLM tool calls suggest.
3. Security Policies & Compliance
Once you can see the behavior, you can govern it. Define what agents are allowed to do (which tools, which endpoints, which files) and get alerted — or blocked — when an agent steps outside those bounds.
What We're Surfacing (The Inventory)
Qpoint observes agent runtimes which contain some or all of the following entities:
| Entity | What it captures |
|---|---|
| Session | The bounded unit of work — start/end, turn count, cost, working directory, parent session |
| Agent | The software that ran it — Claude Code, Cursor, LangChain, version, runtime |
| User | Who initiated it — email (Claude Code), OS username, org identity |
| Endpoint | Where it ran — laptop, CI runner, cloud VM, container; hostname, OS, arch |
| Model | Which model and provider — authoritative from the response; provider host is a property of the model |
| API Key | Which credential was used — hashed, prefix-only display, spend and rate-limit tier |
| MCP Server | Which MCP servers were connected — name, version, tools they exposed |
| Agent Capability | Every tool and skill available to the agent — bash, file ops, web fetch, instruction files, etc. |
| File | Files read or written — path, type, sensitivity flag (credentials, SSH keys, secrets) |
| Secondary Call | Outbound network calls made by tools — github.com, npm, internal APIs |
| LLM Turn | (session-detail) Each request/response — tokens, cost, latency, stop reason, streaming |
| Tool Call | (session-detail) Every tool execution — builtin and MCP unified; inputs, outputs, success/failure, latency |
Why This Matters Now
Security and compliance teams don't yet have visibility into this. The questions they need to answer — who's running agents, what are they doing, what are they accessing, what are they calling — currently have no good answer. Qpoint is positioned to provide these answers