Frequently Asked Questions
Answers for security, platform, and AI engineering teams deploying agents that use tools, APIs, MCP servers, and production credentials.
Kontext Basics
What Kontext is, where it sits, and which teams use it.
- What is Kontext?
- Kontext is runtime authorization infrastructure for AI agents. It turns agent tool calls into local safety decisions as they happen, classifies each action, applies deterministic policy for known hard boundaries, uses probabilistic risk scoring for gray areas, and records allow, ask, or deny decisions for audit. The goal is to let agents work with real systems without giving them standing access to every secret or production resource.
- Who is Kontext built for?
- Kontext is built for security, platform, AI engineering, compliance, and developer-experience teams deploying coding agents, MCP servers, browser agents, internal copilots, and autonomous workflows that touch real data or production systems. These teams need more than prompt instructions or static roles; they need a control layer that can inspect the proposed action before a tool call, credential exchange, file write, or API request happens.
- Does Kontext replace IAM, OAuth, or SSO?
- No. Kontext sits next to existing identity systems. IAM, OAuth, and SSO establish identity, login, and broad authorization. Kontext handles the runtime decision those systems usually do not answer: should this specific agent action be allowed now, under the current user, session, tool, resource, parameters, and policy? That makes Kontext complementary to enterprise identity rather than a replacement for it.
- Can Kontext run locally?
- Yes. Kontext is local by default. `kontext start` launches Claude Code with local policy checks, decision diagnostics, redacted traces, and risk scoring on the developer machine. Teams can add the managed layer when they need browser login, short-lived scoped credentials, shared traces, organization controls, and central review, but the local policy and risk decision path remains the core runtime.
Implementation
How Kontext fits into agent workflows, credentials, and deployment paths.
- How do observe mode and enforce mode differ?
- Kontext starts in observe mode by default, so Claude Code keeps running while Kontext records would allow, would ask, or would deny decisions. Observe mode is useful for tuning policy and understanding agent behavior before blocking work. Set `KONTEXT_MODE=enforce` when you want ask and deny decisions to block supported pre-tool actions. The same local classification, policy, risk scoring, and dashboard diagnostics power both modes.
- How does Kontext issue short-lived credentials to AI agents?
- Kontext avoids writing long-lived provider secrets into agent config. In managed sessions, agents reference provider placeholders in a local environment file. When the agent needs access, Kontext evaluates the session, user, provider, scope, and policy, then exchanges the placeholder for a short-lived credential only for the approved task. The issued credential can expire quickly and be scoped more narrowly than a human-owned API key.
- What is .env.kontext?
- .env.kontext is the managed environment file used by the Kontext CLI when a session needs scoped credentials. It stores provider placeholders rather than raw provider secrets, which means a project can reference credentials without leaving long-lived tokens in source control, shell history, or agent prompts. At runtime, Kontext resolves allowed placeholders into short-lived scoped credentials and leaves literal environment values untouched.
- Where is runtime authorization enforced?
- Runtime authorization should be enforced at the action boundary: immediately before an agent invokes a tool, calls an API, receives a credential, writes data, reads sensitive data, or delegates work to another agent. Kontext sits at that boundary and evaluates concrete request context such as actor, session, tool, resource, parameters, scope, risk, and policy before the action executes.
MCP Security
How Kontext handles MCP authorization, tool permissions, and least privilege.
- How does Kontext work with MCP servers?
- MCP gives agents a common way to discover and call tools, but it does not by itself decide whether a particular call should be allowed for a given user, purpose, or session. Kontext adds a runtime policy layer around MCP tool use. It can evaluate the requested tool, arguments, user context, credential scope, and target resource before allowing, narrowing, escalating, or denying the action.
- How does Kontext enforce least privilege for AI agents using external tools?
- Kontext treats least privilege as a runtime decision, not only a static role assignment. An agent may have permission to use a tool in one context and be denied the same tool in another if the user, task, parameters, resource, or data volume does not match policy. This is especially important for external tools because a valid credential can still be used for the wrong purpose.
- What is a tool invocation privilege boundary?
- A tool invocation privilege boundary is the point where an AI agent's plan turns into a concrete action against a system. Before that point, the model is reasoning. At that point, it is asking to use a real capability. Kontext uses that boundary to inspect the tool name, resource, arguments, credential request, session, and policy so unsafe actions can be stopped before execution.
Compliance
Audit trails, revocation, and regulatory alignment for agent deployments.
- How does Kontext support AI agent audit trails?
- Kontext records structured traces for agent actions, including the user, agent session, tool request, resource, policy decision, credential event, and outcome. That gives security and compliance teams an audit trail that explains not only what happened, but why the system allowed, narrowed, escalated, or denied the action. This is more useful than raw tool logs when investigating agent behavior.
- Which compliance frameworks are relevant to Kontext?
- Kontext is designed around controls that map to modern AI and security governance expectations, including NIST AI RMF, ISO/IEC 42001-style AI management practices, EU AI Act high-risk system themes, OWASP guidance on excessive agency, and traditional audit requirements around least privilege and logging. Kontext is not a legal compliance certification by itself, but it provides evidence and enforcement points that regulated teams need.
- What happens when a credential is revoked or expires?
- Short-lived credentials reduce the window in which an agent can misuse or leak access. When a credential expires, the agent must request access again and pass the current policy check. If an integration, user, or provider connection is revoked, future exchanges can be denied centrally. That lets teams stop new access without hunting through project files for copied API keys.
- Can security teams review agent decisions after the fact?
- Yes. Kontext is built to produce readable traces of agent sessions, credential exchanges, policy decisions, and tool-call outcomes. Security teams can inspect what the agent attempted, what was allowed or denied, which user and session were involved, and which policy influenced the result. This supports incident response, compliance review, tuning, and post-deployment governance for agent workflows.
Guides
Authorization
How agents should be authorized before they use tools, APIs, and credentials.