Frequently asked questions

A secure agent runtime is the infrastructure layer that sits between an AI agent and the downstream APIs it needs to call. Instead of giving the agent a credential, the runtime receives the agent's intent, validates it against policy, injects the credential at execution time, performs the API call, and returns only the response. The agent never holds the key. KeyRunner is purpose-built as a secure agent runtime for enterprise API execution.

Developers can be held accountable for how they use credentials. AI agents cannot. Agents operate across sessions, tools, memory layers, and prompts, all places where keys can leak, be logged, or be exfiltrated. More critically, agents act autonomously: a compromised or misdirected agent with standing API keys has unlimited access until the key is manually rotated. A secure agent runtime solves this by ensuring agents never receive credentials, they receive governed execution.

KeyRunner directly addresses OWASP LLM04 (Model Denial of Service), LLM06 (Sensitive Information Disclosure), and LLM08 (Excessive Agency), the three risks most associated with agents calling external APIs with live credentials. By removing credentials from agent context entirely and enforcing policy at the execution layer, KeyRunner eliminates the attack surface that makes excessive agency exploitable.

Secrets managers store and retrieve credentials, they don't govern how those credentials are used after retrieval. When an agent fetches a secret from Vault, the agent now holds that secret. KeyRunner integrates with Vault, 1Password, and AWS/Azure Key Vault, but it retrieves the credential internally and uses it to call the API directly. The agent receives only the API response, never the credential. The difference is: secrets managers secure storage. KeyRunner secures execution.

API gateways govern inbound traffic to your APIs. They authenticate callers, rate-limit requests, and route traffic. They do not govern outbound agent behavior, which external APIs an agent calls, with what credentials, or under what policy. KeyRunner is an outbound execution layer: it governs what agents can do in the world, not what the world can do to your APIs. Both matter; they solve different directions of the same problem.

An MCP server exposes tools and routes calls - but governance is typically DIY. It does not enforce which agent can call which tool, inject credentials at runtime, redact sensitive data from responses, or require human approval before risky actions execute. You have to build all of that yourself on top. KeyRunner adds policy enforcement, secrets isolation, approval gates, response redaction, and an immutable audit trail as a built-in execution layer over MCP.

API gateways govern inbound traffic to your APIs - they authenticate callers, rate-limit, and route. They do not govern outbound agent behavior: which external APIs an agent may call, with what credentials, or under what policy. KeyRunner is an outbound execution layer. It governs what agents can do in the world, not what the world can do to your APIs. A gateway never sees the moment an agent picks up a tool - KeyRunner sits at exactly that moment.

Prompt instructions are suggestions, not enforcement. An agent can misinterpret them, hallucinate around them, or disregard them under adversarial prompt injection. Telling an agent "never call delete endpoints" in a system prompt has zero enforcement power at execution time. KeyRunner enforces policy at the execution layer - the block happens before the API call goes out, regardless of what the agent was told in its prompt.

Any credential an agent holds can leak into traces, logs, memory, tool outputs, or be extracted via prompt injection. Agents operate across sessions, tools, and prompts - all surfaces where keys can persist or be exfiltrated. A compromised or misdirected agent with a standing API key has unlimited access until you manually rotate it. KeyRunner fetches credentials from your vault only at the moment of execution and passes them directly to the API. The agent never sees the key - not during the call, not in the response, not in the logs.

Non-human identity refers to the cryptographic or token-based identities assigned to AI agents, bots, and automated systems, so systems can authenticate "who is calling" without relying on a human credential. NHI platforms are necessary but not sufficient for agentic security. They establish identity; they do not govern what that identity is allowed to do with downstream API credentials. KeyRunner complements NHI by adding the execution governance layer: even a verified agent can only call APIs it's authorized to call, under policy, with credentials it never sees.

MCP (Model Context Protocol) defines how AI agents discover and call tools. MCP security refers to the controls that govern what those tools can do, who can call them, and what data they can access or return. KeyRunner acts as a secure MCP-compatible execution layer: tools registered in KeyRunner are policy-governed, credentials are injected at runtime, and every tool call is audited. This makes KeyRunner a natural enforcement layer in MCP-based agentic architectures.

Each API registered in KeyRunner is associated with a policy definition: which agents or roles may call it, under what conditions (time, rate, scope, approval), and what data may be returned. When an agent initiates a call, KeyRunner evaluates the request against the policy before any credential is retrieved or any network call is made. Requests that fall outside policy are blocked and logged, not allowed and flagged after the fact.

Yes. KeyRunner exposes governed API actions as callable tools that integrate with any agent framework that supports tool use, including LangChain, CrewAI, AutoGen, Claude, and GPT-based agents. The agent calls the KeyRunner-registered action instead of calling the API directly. From the agent's perspective, it's just a tool call. From the infrastructure's perspective, it's a governed, audited, credential-safe execution.

KeyRunner logs every execution event: which agent made the request, which tool was called, which credential was used (by reference, not value), what the request payload was, what the response was, whether policy was satisfied, and a timestamp. Logs are immutable and can be exported to SIEM systems. This creates an audit trail that satisfies the evidence requirements for SOC 2 Type II, ISO 27001, and HIPAA agent-access reviews.

Yes. KeyRunner is designed for on-premises and private cloud deployment. Execution happens inside your network, credentials fetched from your vault, API calls made from your infrastructure, audit logs stored in your systems. No API request data or credentials transit KeyRunner's servers. This is the architecture that satisfies enterprise security reviews and compliance requirements around data residency.

Because KeyRunner fetches credentials from your secret store at runtime on each execution, rather than caching or distributing them, credential rotation happens transparently. When you rotate a secret in Vault or 1Password, the next agent execution automatically uses the new credential. Agents are never aware of credential values or rotation events, eliminating the operational risk of stale credentials in distributed configs or agent memory.