Solution: Hosted agents

Operate the agents on your infrastructure

Monitor, govern, and secure every agent on every node with a single binary, from background tasks and CI pipelines to production services

Book a Demo
✓Linux✓Kubernetes✓Docker✓CI runners
Workloads

From background tasks to production services

Some are started by an engineer, some by a commit, some by your customers. They run side by side on the same infrastructure, and one deployment of Qpoint covers all of them.

01

Background agents

Engineers hand a task to Claude Code, Codex, or OpenHands running in your sandboxes, and get a pull request back.

Started byAn engineer, from Slack, Linear, or a ticket
Runs onSandbox pods or VMs you operate
Security asksWhat did it touch while nobody was watching?
02

Pipeline agents

Agents run as a step in GitHub Actions, GitLab CI, or Buildkite: reviewing code, fixing tests, writing release notes.

Started byA commit, a pull request, or a schedule
Runs onSelf-hosted CI runners
Security asksCan a PR comment steer it into our secrets?
03

Agent services

Agents your teams build and deploy as services, answering customers and internal users around the clock.

Started byEnd users, through your product or tools
Runs onKubernetes or VMs, long-running
Security asksWhat can it do on a customer's behalf?
How it works

A single binary on Kubernetes, containers, or Linux hosts

Pick the method that fits your workload. Every option reports to the same control plane, in your environment.

DaemonSet
Kubernetes
  • Covers: Every pod on every node, including ones scheduled later
  • Ships as: Helm chart or a manifest
  • Restarts: None. Running pods are untouched
  • Updates: Roll the DaemonSet
Container image
Docker, ECS, Nomad
  • Covers: The container it ships in
  • Ships as: One line in the Dockerfile or your base image
  • Restarts: Redeploy the image
  • Updates: Bump the tag
Linux package
VMs, bare metal, CI runners
  • Covers: Every process on the host
  • Ships as: Single download binary with checksum
  • Restarts: None
  • Updates: Package manager
Identity

Every session has an identity

Qpoint records what every session runs as: the service account it started under, the tokens and credentials it presents when it makes requests, and the team that owns it through the labels you already use. What identity an agent assumes when it acts is the question nobody can answer today.

01

Background agents

The session runs as the sandbox's service account, with whatever credentials are mounted into the pod. Every request it makes carries that identity.

session 7a19f0 · claude-code · bg-agent-4c2dSECRET · REDACTED
00:00
identitysa sandbox-runner · aws role agents-dev
00:01
session startpod bg-agent-4c2d · ns agents
00:06
file readtests/checkout_test.py
00:31
request · redactedapi.anthropic.com · AWS key removed from prompt
01:12
process spawngh pr create --title "Fix flaky checkout test"
runs assa sandbox-runneraws role agents-devteam paymentspod bg-agent-4c2d
02

Pipeline agents

The session runs as the job: the runner's token, the repo's deploy keys, and any cloud role the workflow assumes.

session c41e02 · codex · github-actions #8823419FILE READ · BLOCKED
00:00
identityrunner token ci-7f3a · oidc role ci-deploy
00:01
session startrunner ci-7f3a · workflow ai-review.yml
00:04
file readdiff · 14 files
00:18
file read · blocked/var/run/secrets/…/serviceaccount/token
00:22
requestapi.openai.com · 8.1k tokens
00:40
tool callpost_review_comment · 6 comments
runs asrunner token ci-7f3adeploy key acme/paymentsoidc role ci-deployteam platform
03

Agent services

The session runs as the service, using its own service account and API credentials, with the end user attached to each call.

session 5d8b31 · support-agent · ns supportTOOL CALL · DENIED
00:00
identitysa support-agent · crm api key · end user cu_8812
00:01
tool callcrm-mcp › lookup_customer · allowed
00:02
requestapi.anthropic.com · 3.2k tokens
00:03
tool call · deniedbilling-mcp › issue_refund · $2,400 over limit
00:04
responseescalated to a human agent
runs assa support-agentcrm api keyteam cxend user cu_8812
# /etc/qpoint/qpoint.yaml

sinks:
  - url: otlp://otel-collector.internal

targets:
  claude:
    harness:
      mode: inspect
    tap: endpoint_harness

  codex:
    harness:
      mode: enforce
    tap: endpoint_harness

taps:
  endpoint_harness:
    plugins:
      - name: mcp-credentials
        config:
          secret_provider: vault.internal
Setup

Zero configuration per agent

Ship it as a ConfigMap, bake it into the image, or drop it on the host. The same file covers every node.

Sinks are where events go: OTLP, Splunk HEC, Datadog, Elastic, S3, or whatever you already run.
Targets name the agents you want covered, set to inspect or enforce.
Taps hook into a running agent and specify the plugins that apply policy.
Plugins decide what happens to each action: log it, tag it, rewrite it, or block it. Use the built-in ones or write your own.
For Platform and Security Engineering

Know what's running. Prove what happened.

Cluster-wide coverage for the teams that run the platform, and the evidence for the teams that answer for what runs on it.

Service-level inventory

Every agent by service, namespace, and job. Coverage comes from the node, so pods that reschedule and runners that live for minutes are covered without registering anything.

Cost by service and team

Tokens and spend by service, job, provider, and model. Chargeback follows the team label, not a shared API key.

Protected service credentials

Service account tokens, cloud IAM credentials, and deploy keys are blocked from agent reads, and every attempt is logged with the pod, job, and service account.

No code changes required

No SDK, no sidecar per agent, no wrapper around the entrypoint. Workloads run exactly as they did before.

Nothing leaves your environment

The control plane and the event stream run on your infrastructure. Qpoint never sees your data.

Policies as plugins

Use the built-in plugins or write your own against the same hooks: log, tag, rewrite, or block any file read, tool call, or outbound request.

Solutions

Run Qpoint wherever your agents run

Laptops, servers, and other people's products. One binary, one event stream, deployed where the agents are.

Endpoints
Employee and engineer laptops, rolled out through MDM
Hosted agentsYou are here
Containers, VMs, and clusters where agents run as services
Embedded
Qpoint built into your own platform or product
Get Started

Seconds, not sprints

Qpoint deploys as a single binary on every node. No gateways to route through, no sidecars to add, no SDK integration to schedule.

Install, run, and start seeing every AI agent in the cluster — in under a minute.

$ helm install qpoint qpoint/qpoint -n qpoint --create-namespace
Book a Demo