AI Agent Security, Risk & Governance FAQ — Kohala

Plain-English answers about Kohala's product evolution, AI agent security and risk boundaries, governance controls, imports, managed deployment, and connected agents.

Latest Community Questions

Explore Kohala

Frequently Asked Questions

How has Kohala evolved?
Kohala began with Living Koans and tools for building agents. It now also helps teams govern code they already have or create new agent code with Kai, then operate that work with explicit runtime controls and evidence. Koans remain a first-class way to publish a live result; they are no longer the whole product.
Why focus on security, risk, and governance?
Getting an agent to work once is different from trusting it with ongoing access to data, tools, and budgets. Kohala's focus is making that operation easier to inspect and control: what the agent is intended to do, which supported tools it may call, where it runs, which limits and approvals are configured, and what happened during a run. Building agents and publishing Koans remain part of that larger operating model.
Do I have to build a new agent in Kohala?
No. You can ask Kai to help build an agent, import supported agent code to Kohala's managed runtime, or connect a supported external agent that continues to run on your infrastructure. The right path depends on its framework and on where you want execution responsibility to sit.
Which frameworks can be imported, and which only connect?
Python agents (LangChain, LangGraph, CrewAI, the OpenAI Agents SDK, and PydanticAI) and TypeScript agents (LangGraph.js) can be imported and run on Kohala's hosted runtime; n8n connect from where they already run and report each run; Claude source is statically inspected by Kai's specialists and redesigned as a native Kohala agent before approval.
What makes up a Kohala agent?
An agent can have six distinct parts: a script, memory, a schedule, Koans, alerts, and governance settings. They work together, but each is configured separately so an operator can see what exists and decide what should be enabled.
Does importing code create all six agent parts automatically?
No. An import brings supported code through a review and setup path; it does not magically create memory, a schedule, Koans, alerts, or every governance setting. Review the resulting agent and deliberately configure the parts it needs before relying on it.
What is the difference between build, deploy, and connect?
Build means creating or adapting agent code, including with Kai. Deploy means running supported imported code on Kohala's managed runtime. Connect means the agent stays on external infrastructure and reports runs into Kohala. Connect-only support is not the same as a hosted deployment.
Does Kohala guarantee that an agent is safe?
No. Kohala provides controls, run evidence, and risk signals that can help people operate agents more carefully. Those features do not prove that code, model output, or an external action is safe, and no risk score should replace testing, review, or incident response.
Does a tool allowlist cover every possible network request?
No. The runtime can refuse calls made through its scoped, brokered native and MCP tool paths when a tool is outside the configured allowlist. That is not a blanket guarantee against arbitrary direct network access in every script, hosted framework, or external connected environment.
Do output validators prevent or roll back harmful actions?
No. Configured validators examine output after execution. A failed verdict can mark and record the run as failed, but it does not undo an API call, message, purchase, file change, or other side effect that already happened.
Is human approval required for every consequential action?
No. Human-in-the-loop behavior must be explicitly configured through the available per-agent policies or requested by the agent through the approval tool. Approval is not automatically applied to every action, and relevant policies can be off.
What happens when I pause an agent?
Pause is per agent and stops new runs from being admitted. It is not a fleet-wide kill switch, and it does not cancel a run that is already in flight. Treat an active incident involving external side effects as an operational response, not only a pause-button task.
How does the security boundary differ for managed and connected agents?
For code on Kohala's managed runtime, Kohala can apply the controls implemented at that runtime's supported execution paths. A connected agent still executes on infrastructure you control; it reports runs, but Kohala does not become the security boundary for that external host, its credentials, or all of its network activity.
Is learned risk monitoring generally available, and does unavailable mean zero risk?
Learned-risk inference should not be assumed available for every agent or account. Collecting run evidence is different from having a validated model that can assess it. An unavailable or partial result means that a score could not be established—not that risk is zero. Use the controls and evidence available for your execution path, and review uncertainty rather than treating it as an assurance of safety.
Does an agent charter enforce its intent?
Not by itself. A charter is operator-written intent placed in the agent's context. It guides behavior, but it is not a general policy engine. Use concrete controls such as a deliberately scoped brokered tool allowlist, configured approvals, limits, and validators for the paths they actually cover.
What should a team review before putting an agent into production?
Review the executable code, credentials, execution location, brokered tools, direct network paths, schedule, memory, outputs, alerts, approval settings, limits, validators, and failure response. Test realistic side effects and document which responsibilities remain with the external framework or host.
Does using Kohala make my organization compliant?
No platform alone establishes compliance. Kohala's configured controls and run evidence can support your review process, but your organization remains responsible for applicable laws, data handling, access policies, vendor reviews, and human oversight. A charter or successful validation is not a certification or legal opinion; verify any required enterprise capability before relying on it.
What evidence can I review when an agent runs?
Use the agent's run records and available traces to inspect execution status, outputs, usage, and recorded tool activity. Evidence depends on the execution path and what was actually captured: a connected agent's reports do not prove that every external action was observed. In-product visibility is not a promise of downloadable audit exports or a SIEM integration.