Frequently Asked Questions About AASB and Unbound AI

An Agent Access Security Broker, or AASB, is a new control category purpose-built to govern the runtime behavior of AI coding agents inside an enterprise. It sits between the agent and everything the agent can touch: the terminal, the filesystem, MCP servers, and sensitive data. It enforces centrally defined policy over what agents can and can't do. The analogy is direct. CASB emerged a decade ago to secure employee access to cloud apps. AASB exists because the same problem now applies to autonomous agents acting on developers' behalf with full credentials and terminal access. Unbound AI is the first AASB on the market, covering discovery, assessment, and policy enforcement across every coding agent, MCP server, and tool integration in an engineering organization.

AI coding agent security is the practice of governing what autonomous coding agents like Claude Code, Cursor, and Codex can do inside a developer's environment and across an organization's systems. It is not the same as securing the AI model, filtering prompts, or scanning the generated code. The surface area is the agent itself: shell commands it executes, files it reads and writes, MCP servers it connects to, credentials it uses, and the autonomy level at which it operates. Traditional application security tools like SAST, DAST, and SCA scan code after it is written. Agent security must sit earlier in the loop, with visibility into which agents developers are running, assessment of their configurations against security benchmarks, and policy enforcement at the point the agent acts.

Three categories of risk, all of which scale with agent autonomy. First, credential and system access: every coding agent runs with full developer permissions, meaning shell access, git credentials, cloud CLI tokens, and database access are all available to a process that takes instructions from natural language. Second, data exfiltration: agents read source code, environment files, and secrets, and send them to LLM providers as context. Without redaction, this is how proprietary code and API keys end up in training data. Third, untrusted tool execution via MCP: the Model Context Protocol lets agents connect to third-party tools and servers, each of which can execute code or access systems with the agent's permissions. Security teams typically have zero visibility into which MCP servers developers have connected, what those servers do, or when the agent hands off control.

Unbound AI deploys through two complementary entry points. At the coding agent account level, Unbound integrates with native hooks that agents like Claude Code, Cursor, and Codex expose for enterprise controls, so org-wide policy is enforced the moment a developer signs in. At the workstation level, a simple script deployed through the customer's MDM provider (JAMF, Intune, Kandji) installs a lightweight endpoint agent that observes coding agent activity inside the IDE and terminal: shell commands, file access, MCP server connections, and data sent to LLM providers. Policies defined centrally by the security team are evaluated at the point of action, with the option to audit, warn, block, or require human approval. The deployment is designed to be zero-disruption. Developers keep their existing tools, workflows, and productivity, and Unbound enforces governance in the background.

Unbound supports every major enterprise AI coding agent: Claude Code, Cursor, GitHub Copilot, Codex, Windsurf, Cline, Roo Code, Gemini CLI, and Kilo Code. It also governs any agent that uses the Model Context Protocol, or MCP, to connect to external tools. Beyond coding agents, Unbound extends to the Claude Desktop app, which brings knowledge workers and non-developers under the same policy framework (see the next question for detail). The point of coverage is deliberate. Policy is defined once and enforced consistently across every agent, so security teams don't need to learn the idiosyncratic warnings and guardrails of each tool, and developers don't get to pick which agent has the weakest controls. If a new agent lands next quarter, it comes under the same policies the day Unbound adds the integration.

Yes. Unbound supports the Claude Desktop app, which extends the platform beyond engineering to knowledge workers who use AI for daily workflow automation: analysts running research, operations teams drafting reports, go-to-market teams building decks, legal reviewing contracts, and anyone else using Claude Desktop as their day-to-day AI interface. The governance model is the same as for coding agents. Discovery finds every Claude Desktop install across the workforce. Assessment surfaces risky MCP connections and autonomy settings. Policy enforcement controls what the desktop agent can do: which data it can send to Anthropic, which files it can access, and which local or remote tools it can invoke. For enterprises adopting AI broadly, this means one AASB covers both the engineering org and the knowledge worker population under a single policy framework, rather than bolting separate controls onto each audience.

MCP, the Model Context Protocol, lets coding agents call external tools and servers. It is the fastest-growing blind spot in enterprise AI security. Unbound discovers every MCP server connected to every coding agent in the organization, assesses each server against risk criteria like untrusted source, dangerous permissions, and unknown publisher, and enforces policy on what agents are allowed to call which servers. Policy can be set per team, per server, or per action. A security team can block all filesystem-write MCP tools in production, require approval for any MCP server published in the last 30 days, or permit a known-good set with audit logging. Security teams get the visibility they were missing. Developers keep the agent velocity they want.

No. Unbound monitors agent behavior metadata, not source code content. Telemetry captures which tool was invoked, which file was accessed, which MCP server was called, and which model received a request. No code is copied, stored, or sent to Unbound's cloud infrastructure. This is a deliberate architectural decision. Security telemetry needs to be comprehensive, but it does not need to be intrusive. For enterprise customers who need content-level controls (for example, secret redaction before a request leaves the environment), processing happens in-memory only and is not persisted unless an admin explicitly enables logging. If logging is enabled, enterprise customers can configure logs to write to their own cloud storage with write-only access roles, so Unbound never retains copies.

SAST and DAST inspect code and running applications for vulnerabilities. They are necessary, and they do not solve agent security. The gap is temporal and behavioral. SAST runs after code is committed. DAST runs against an application in a test environment. Both miss the window in which an AI coding agent, acting autonomously with developer credentials, can install a malicious package, leak an API key, or execute a destructive shell command. AASB operates during the act. Unbound's controls evaluate agent actions at runtime, at the endpoint, before any code is produced or any command is run. Think of the relationship the way you think about CASB versus antivirus: different layers of the stack, both needed, neither a substitute for the other.

Built-in agent controls are per-tool, inconsistent, and developer-controlled. Every agent has its own warnings, its own permission prompts, and its own settings file. A developer can disable them. A security team cannot centrally enforce them, cannot audit them, and cannot see what the developer actually approved. Unbound replaces that patchwork with a single, centrally defined policy that every agent respects. The policies are consistent across Claude Code, Cursor, Codex, Windsurf, and the rest. Enforcement is not advisory. Unbound can block an action, not just warn, and approvals route to a security reviewer rather than to the developer who is trying to ship code in the next five minutes.

CASB secures employee access to cloud applications: who can log into Salesforce, which files can leave Dropbox, which SaaS apps are approved for enterprise use. AASB secures agent access to tools, files, systems, and actions: which coding agents are running, what terminal commands they can execute, which MCP servers they can invoke, and what data they can send to which LLMs. The analogy matters because the control pattern is the same. A new class of non-human actor has gained broad access to enterprise resources, and the existing security stack has no native way to see or govern it. Unbound is applying the CASB playbook to agents, with discovery, assessment, and policy enforcement built for autonomy that didn't exist when the first CASBs were designed.

Deployment is measured in days for a full org rollout, minutes for an individual user. Unbound uses two entry points that can be staged independently. Native hooks at the coding agent account level are activated centrally from the Unbound dashboard and take effect for every user who signs in. The workstation-level agent is packaged as a simple script that the customer's MDM provider (JAMF, Intune, Kandji) deploys automatically across every laptop in scope. Security teams can start with discovery in read-only mode to get visibility first, then layer on policy enforcement once the baseline is understood. Developer workflows and productivity are unaffected throughout. The 30-day Pro trial requires no credit card, no sales call, and no feature gating, which means a security lead can validate the product on their own environment before involving procurement.

Yes, Unbound AI is SOC 2 compliant and available on AWS Marketplace. On data privacy, three commitments. No source code leaves the developer environment. Analytics run in-memory with no persistent storage of prompt content unless an admin explicitly enables logging. Enterprise customers can route sensitive requests to private LLMs in Google Vertex AI, AWS Bedrock, or confidential computing infrastructure rather than external providers. Authentication integrates with enterprise identity systems via SAML, OIDC, and SCIM, so access control follows the same directory your other security tools already do. For regulated industries or environments with strict data residency requirements, Unbound's architecture is designed so the bulk of runtime governance happens at the endpoint, not in Unbound's cloud.