> For the complete documentation index, see [llms.txt](https://docs.havl.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.havl.io/products/havl-guard.md). # havl guard **havl guard** is the human oversight layer for autonomous AI agents. It enables agents to operate independently during normal workflows while introducing human oversight at defined boundaries — before actions are executed, when uncertainty becomes too high, or when a situation requires human judgment. Instead of requiring approval for every step, clients define **when an agent can act autonomously and when a human needs to be involved**. **Agents operate. Humans oversee.** ### Human oversight for autonomous agents AI agents are increasingly able to do more than generate information. They can use tools, interact with external systems, communicate with people, modify data and initiate transactions. As their autonomy increases, the question changes from: **“Is this AI output correct?”** to: **“Should this action actually happen?”** havl guard creates a human checkpoint between an agent's intention and execution whenever predefined conditions are met. The agent can continue operating autonomously within its normal boundaries. When it reaches a configured guardrail, the proposed action and relevant context are sent to human verifiers. ### When can humans be involved? Guardrails can be configured around the specific risks and requirements of an agent workflow. Typical triggers include: * financial transactions * irreversible actions * sensitive external communications * access or permission changes * deletion or modification of important data * policy exceptions * unusual agent behavior * conflicting information * low-confidence decisions * actions above defined value or risk thresholds Clients determine which actions require oversight and which can continue automatically. This allows human involvement to remain proportional to risk rather than becoming a bottleneck for the entire agent. ### Configurable oversight Different actions require different levels of human involvement. #### Approve The proposed action is reviewed before execution. If the verifier approves it, the agent can continue with the original action. #### Reject The verifier determines that the proposed action should not proceed. The agent receives the rejection and can stop, choose an alternative path, or follow predefined fallback logic. #### Modify A proposed action can be adjusted before execution. For example, a verifier could correct a parameter, modify a message, change a transaction amount, or provide additional instructions to the agent. #### Escalate Some situations cannot be resolved through a simple approval decision. The task can be escalated to additional verifiers, a Certified Expert, the client's internal team, or another predefined escalation path. ### Human-on-the-loop havl guard is designed around **human-on-the-loop oversight** rather than continuous human control. The agent remains autonomous by default. Humans become involved when the system reaches a boundary where additional judgment is valuable or required. This creates a middle ground between two extremes: **Fully autonomous**\ The agent acts without independent human oversight. **Human-in-the-loop**\ A human must participate in every relevant step. **Human-on-the-loop with havl guard**\ The agent operates autonomously, while humans intervene at defined checkpoints, exceptions and high-risk decisions. The result is autonomy with an independent layer of human oversight. ### Risk-based guardrails Not every action carries the same consequences. havl guard allows clients to create different oversight requirements based on the risk or importance of an action. A routine internal update might require no intervention. A customer-facing message might require one human approval when certain conditions are triggered. A significant financial transaction could require multiple independent approvals or verification by a Certified Expert. This allows oversight to scale with the potential impact of the agent's actions. ### Independent human judgment The verifier receives the information required to understand the proposed action without needing access to the client's entire system. Depending on the task, this can include the agent's proposed action, relevant context, reasoning or supporting information, applicable policies and clearly defined review criteria. The verifier then provides a structured decision according to the client's requirements. For higher-risk actions, multiple independent verifiers can be required to reach consensus before execution is authorized. This creates an additional decision layer outside the autonomous agent itself. ### Autonomy with boundaries The goal of havl guard is not to make autonomous agents less autonomous. It is to make their **boundaries explicit**. Agents should be able to perform routine work quickly and independently. But financial commitments, irreversible changes, sensitive decisions and unexpected situations may justify a different level of oversight. havl guard provides the human layer at those moments. **Autonomy where possible. Human judgment where it matters.** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.havl.io/products/havl-guard.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.