Securing AI agents at runtime: what a valid sign-in does not cover

Why is a valid sign-in not enough?

AI agents do not only work with text. Coding agents such as Claude Code from Anthropic or Codex from OpenAI read files, run commands, call interfaces and change code. They do so with the permissions of the person who started them, often on that person’s workstation.

The sign-in answers only one question: is this access allowed to do this in principle? It does not answer whether a single action fits the task. An agent can be correctly signed in, use an approved tool and still do something nobody wanted: read a file with credentials, delete a directory or send data to an unknown address, for example because a manipulated web page suggested it.

What is runtime protection?

Runtime protection steps in at the point where an agent calls a tool. Before every execution, it checks:

Question	Example
Who is acting?	which agent, on behalf of which person
What is supposed to happen?	run a command, read a file, call an interface
What is the action aimed at?	directory, system, network address
Does this fit the task?	change code for project A, not read credentials from project B

Depending on the rule, the call is allowed, blocked or reported. Every decision is logged so that it can later be traced what an agent did and why. The OWASP collections on generative AI and MITRE ATLAS, for example, serve as frames of reference for risks.

How does Kontext work?

Kontext is a security platform for AI agents from CoBrowser Technology GmbH in Munich, founded by Jens Ernstberger and Michel Osswald. In September 2026, the company announced funding of USD 4 million, led by 42CAP, with a16z CSX and the High-Tech Gründerfonds.

According to the provider:

• Finding agents: Kontext detects AI agents on workstations and shows what they can access.
• Rules at runtime: For Claude Code and Codex, Kontext checks every tool call before execution, through interfaces that these agents offer for this purpose. It detects other agents without controlling them.
• Observe first, then block: In observation mode, Kontext shows what would be blocked. Blocking can be switched on once the rules fit.
• Logs and overview: Every decision is recorded, together with a risk assessment and an overview of the agents’ costs.
• Operation: A program on the computer checks the calls locally; it is available under the MIT licence on GitHub. Administration and overview run in a service of the provider. macOS is currently supported.
• Pricing: a free tier, a tier for teams and an offer for large organisations, published on the website.

The provider states on request where the service is operated and which proof is available.

What should organisations clarify before using agents?

1. Know what is in use: Which agents are already running on computers in the organisation, often without central approval? This is the same question as with shadow IT.
2. Define tasks: What may agents be used for, and what not?
3. Limit access: Let agents work only in the directories and systems the task needs; do not store credentials in plain text.
4. Observe rules first: Have rules only report at first and align them with practice.
5. Evaluate logs: Who reads the logs, and what happens when a rule is triggered? This belongs in information security management, see audit logs and traceability.
6. Check data protection: Which contents of the calls go to a service outside the computer, and where is it operated?

How does this work with basebox?

basebox is an AI platform, not runtime protection for agents on workstations. The two complement each other: anyone in IT who uses coding agents secures them separately; the rest of the organisation works in basebox.

In basebox, fixed rules apply to access to systems. Connectors read with the permissions of the person asking, without a shared service account, and by default read-only; write access is only available after agreement. Your administrator determines for each app which connectors it may use, and every connector call is recorded in the audit log. From November 2026, workflows from the App Builder handle tasks on their own; write actions such as forwarding only after approval by a person.

Note: The information on Kontext reflects the state of our research on 15 October 2026 and is based on the provider’s own statements. For your own use, check features, operation and contracts with the provider.