Underneath the Agent

Your Agents Need a Dynamic Sandbox

Block an AI agent from an external API, then it tries to curl. Block curl and it writes a Python script and runs that instead. That’s the problem with most agent sandboxes today: they’re static. Your security team writes the rules upfront before an agent runs, and the agent spends the session finding paths around the static guardrails that have been set.

What Your AI Assistant Can't See (And How to Fix It)

Your AI coding assistant can read every line of your code. But when that code makes an HTTP request, your AI has no idea what comes back. Here's how to give it eyes on live network traffic.

Introducing DevTools: Chrome-style Network Tab for Your Linux Server

We built a browser-based debugging tool that shows live http/s traffic on production servers. No proxies, no certificates, no code changes. Just the visibility we always wished we had.

Write a Qpoint policy from scratch

Some agent risks are easy to predict, like a git force push that rewrites a shared branch. Others are harder to predict, like an agent finding a new way to send data off the machine. A single Qpoint policy can cover both. In this demo, we write a policy from scratch. We start with simple rules that block force pushes and limit agents to an approved list of MCP servers. Then we add a rule that has an AI judge review each command and flag any that send sensitive data to an outside server.

Control the hidden agent surface

Agents write and run scripts, and the agent harness can’t see which files those scripts read or where they send requests. Qpoint runs underneath the agent, so its policies apply to what those scripts do. In the demo, one rule flags any read of a secrets file, catching Claude Code with curl and again with a Python script, then blocks the read when the rule is switched to deny.

Enforce an agent’s purpose

An agent often needs permission to use a tool, but not for everything that tool can do. A pull request review agent needs to post comments, for example, but it shouldn’t approve the PR on behalf of the team. Qpoint uses a System One model to check each action against the purpose you define for the agent, so the review comments go through and the approval is blocked, even when the project’s instructions tell the agent to approve it.

Catch an agent retrying a denied action

When an agent is blocked from doing something, it often tries again a different way. Qpoint looks at the recent history of the session to tell when a new action is really a workaround for something that was just blocked. In the demo, an agent that can’t comment on GitHub through its MCP server tries the GitHub CLI instead, and Qpoint catches it.

Restrict where agents send data

Agents need to read from the web, but you probably want control over where they send data. With this policy, agents can still read from any site, but they can only send data to destinations you’ve approved. It also blocks the agent’s own telemetry from being sent out.

Keep agents out of your secrets

Most machines have files with passwords and tokens that any agent can read. A single Qpoint policy stops agents from reading those files, whether they open the file directly, use a command, or write a script to do it. In the demo, the policy stops both Claude Code and Grok.