Frequently Asked Questions

Kontext Basics

What Kontext is, where it sits, and which teams use it.

What is Kontext?

Kontext is the runtime security platform for your AI workforce. Discover agents, map what they can access, block prohibited actions, detect risk in agent behavior, and manage spend to reduce costs. Keep evidence for every policy decision.

Runtime authorization guide

How does Kontext help with agent discovery and posture management?

Kontext helps teams identify agents in connected environments and map the tools, systems, and data they can access. Reviewing that posture alongside observed actions shows where access creates risk. Teams can then validate policies and block prohibited actions at supported control points, retaining decision evidence for review.

Which agents does Kontext support?

Kontext protects your AI workforce, from coding assistants and workplace agents to custom-built agents, across endpoints and cloud environments. Bring agent discovery, access policies, risk monitoring, and spend management together across the agents your organization uses.

How does Kontext help manage agent spend?

Understand agent spend, identify waste, and find savings by reducing unnecessary costs.

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, file write, or API request happens at a supported control point.

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.

Authentication vs authorization OAuth for MCP agents

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 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 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.

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.

Tool invocation boundary

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, asking for review, or denying the action.

OAuth for MCP agents

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.

Least privilege guide

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, session, and policy so unsafe actions can be stopped before execution.

Privilege boundary explainer

Compliance

Audit trails 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, risk signal, and outcome. That gives security and compliance teams an audit trail that explains not only what happened, but why the system allowed, escalated, or denied the action. This is more useful than raw tool logs when investigating agent behavior.

Agent compliance guide

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.

NIST AI RMF guide Excessive agency guide

Can security teams review agent decisions after the fact?

Yes. Kontext is built to produce readable traces of agent sessions, 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