What Makes an AI Agent Runtime 'Secure'? (It's Not Just HTTPS)

When an AI tool vendor describes their product as "secure," they almost always mean the same thing: the connection between your client and their server uses TLS. That is true of every modern web service. Calling it a security feature is like calling a building "safe" because it has a front door. The front door is necessary. It is not the thing that makes the building safe.

For AI agent runtimes that touch production codebases, the security questions that actually matter are several layers deeper. Where is your code being stored? Who controls the credentials the agent uses to access it? What happens if an engineer who left the company last month still has active API keys in their local MCP config? Can your compliance team produce an audit log of what the agent read? Can an attacker manipulate the agent's behavior by injecting instructions into the repository it is indexing?

These questions have answers. Most tools do not surface those answers prominently, and most teams do not ask them until something goes wrong or a compliance audit forces the conversation.

The security dimensions that matter

What security actually means for an AI agent runtime:

  Transport security (TLS)
  -> Encrypts data in transit between agent and endpoint
  -> Standard in every modern web service
  -> Minimum bar — necessary but not sufficient

  Data residency
  -> Where indexed code representations are stored
  -> Which jurisdictions the data passes through
  -> Relevant for SOC 2, GDPR, HIPAA, and enterprise contracts

  Secret isolation
  -> Credentials used by the agent (API keys, tokens) are not on developer machines
  -> Secrets stored in a vault, not in plaintext config files
  -> Rotation and revocation controlled from one place

  Access scoping
  -> Agent can only access what it is authorized to access
  -> Least-privilege: read-only access unless write is explicitly required
  -> Per-user or per-role scoping, not a single shared credential

  Audit logging
  -> Record of what the agent read, not just what it wrote
  -> Queryable for compliance reviews and incident investigation
  -> Tamper-evident log that persists beyond the agent session

  Prompt and context integrity
  -> Protection against prompt injection through malicious repository content
  -> Validated MCP tool definitions (not copied from untrusted sources)
  -> Agent cannot be instructed to exfiltrate context by content in the codebase

Transport security is the prerequisite. Everything else on that list is what distinguishes a tool that passed a surface-level security review from a tool that can withstand a serious audit.

Data residency: where does your code actually go?

When an AI agent indexes your codebase, it creates representations of your code — embeddings, summaries, call graphs, dependency maps — that are stored somewhere. Where that somewhere is matters for compliance. GDPR has requirements about data leaving the EU. HIPAA has requirements about where healthcare data is processed and stored. Enterprise contracts often include clauses about code not leaving specific cloud regions or provider environments.

Most AI coding tool vendors have data processing agreements that cover some of this, but the coverage varies significantly. For developer-side tools like Claude Code or Cursor, code snippets sent to the model API may be processed in any region depending on the vendor's infrastructure. For managed codebase MCPs, the indexed representations of your code live on the vendor's infrastructure in whatever region that vendor operates.

For local tools like Context+, data residency is trivially controlled — everything stays on the developer's machine. But this trades one compliance concern (data leaving the network) for another (code living on personal developer laptops that are not subject to the same physical and logical access controls as your production systems).

Secret isolation: where are the credentials?

AI coding tools that connect to external systems — GitHub repositories, Jira projects, database schemas — require credentials to do so. The question of where those credentials live is the single most consequential security question in AI tool deployment.

Per-developer MCP configuration, which is the standard model for tools like Context+ and community codebase MCPs, stores credentials in local config files on developer machines. Those files are in dotfile directories that developers sometimes push to version control. GitGuardian found 24,008 secrets in MCP config files on GitHub in 2025. The credential model directly caused those exposures.

Secret isolation requires a different architecture: credentials live in the platform's vault, not on developer machines. Developers authenticate to the platform using SSO or scoped tokens. The platform uses its own service credentials to access connected systems. When a credential needs to be rotated, it is rotated in the platform's vault. When a developer leaves the company, their access to the platform is revoked — which is the same as revoking their access to every system the platform connects to, automatically.

Access scoping: what can the agent actually do?

The principle of least privilege says systems should be granted only the permissions they need to do their job. Applied to AI agent runtimes, this means the agent should not have write access to your repositories if its job is to answer questions about them. It should not have access to your production database credentials if it only needs to understand the schema. It should not be able to run arbitrary commands in your infrastructure if it only needs to read code.

Many AI coding tools, especially local ones, operate with whatever permissions the logged-in developer has on their machine. That means the agent inherits full developer-level access to every system the developer can reach. This is convenient and it is a security anti-pattern. An agent that can read every file on the developer's machine, run arbitrary shell commands, and connect to every service the developer's credentials allow is an agent that, if compromised through prompt injection or tool poisoning, has an enormous blast radius.

A secure managed runtime scopes agent access explicitly. Read-only access to indexed repositories. API access limited to specific endpoints. No shell execution unless explicitly granted for an agentic workflow that requires it.

Audit logging: what did the agent read?

Compliance frameworks like SOC 2 require audit logs of access to sensitive systems. For source code — which for most companies is among the most sensitive data assets — the audit question is not just "who committed what." It is "what did the AI agent read before it made those changes?" That question currently has no good answer for most AI coding tools.

Git records commits. It does not record what an AI agent read from the codebase while generating a commit. A developer using Claude Code with a codebase MCP may have had the agent read across fifteen services before making a targeted change in one. The commit records the change. Nothing records the reading. For compliance purposes, this is an access log gap.

A managed agent runtime that routes all codebase access through a central endpoint can produce this log. Every query to the MCP is logged: who asked, what they asked, what was returned, when. That log is the audit trail that answers "what did the AI have access to during this session" — a question that security and compliance teams are increasingly asking as AI-generated code becomes a standard part of software development.

Prompt and context integrity: can the codebase manipulate the agent?

MCP tool poisoning is a documented attack vector: malicious content embedded in a repository — in a README, a code comment, or a configuration file — can include instructions that manipulate an AI agent's behavior when the content is indexed and served as context. This is a form of prompt injection where the attacker's surface is the codebase itself.

Check Point disclosed CVEs in Claude Code in 2025 (CVE-2025-59536, CVE-2026-21852) that allowed remote code execution through malicious repository configuration files. OX Security found an architectural vulnerability in the MCP protocol itself that affected 150 million downloads. These are not theoretical vectors — they are documented exploits against production AI coding infrastructure.

A secure agent runtime validates MCP tool definitions before serving them to agents, detects anomalous content in indexed context, and limits what the agent can be instructed to do regardless of what content appears in the indexed material.

What common tools actually provide

Security properties in common AI coding tools:

  Cursor          | TLS ✓ | Data residency varies | Secret isolation ✗ (keys in local config)
  Claude Code     | TLS ✓ | Anthropic data policy  | Secret isolation ✗ (keys in local config)
  Context+ (MCP)  | N/A   | Local only             | Secret isolation ✗ (Ollama on laptop)
  GitHub Copilot  | TLS ✓ | GitHub data policy     | Secret isolation varies
  Kognita         | TLS ✓ | SOC 2 Type II          | Secret isolation ✓ (OAuth, no keys on devices)

That comparison is not an indictment of any specific tool — different tools make different trade-offs for different use cases. Claude Code is excellent for developers doing agentic coding work; its security model is appropriate for that use case. Context+ is designed for local use; its security model is appropriate for a developer working alone on a local machine.

The comparison becomes relevant when a security team is evaluating which tools to approve for production use across an engineering organization, or when a compliance audit asks about access controls around AI tooling that touches source code.

Final take

Security for an AI agent runtime is not a single property. It is a stack of properties — transport, residency, secret isolation, access scoping, audit logging, and prompt integrity — where each layer is a necessary but insufficient condition for the next. Teams that ask only about encryption are asking about the front door while leaving the windows open.

As AI coding tools move from individual experiments to team infrastructure, the security questions get harder because the blast radius gets larger. One developer experimenting with a local MCP is a limited risk. A team of fifty developers with AI agents reading across the full codebase, without audit logging, with credentials scattered in local config files, without scoped access — that is a different risk profile entirely.

A managed secure agent runtime is one where credentials live in a vault, access is scoped to what the agent needs, queries are logged for audit, and the architecture is not vulnerable to manipulation through content in the repositories being indexed. That is not a description of TLS. That is a description of infrastructure built for production use.