Guides

The concept pages explain how Qortara governance works. The guides are where you do it. They are written for engineers who are wiring governance into a real agent, not for a sales evaluation, so the examples are concrete and runnable, and they are explicit about what you can run today versus what is pre-launch.

The aim of this section is to take you from a first, deliberately narrow policy to a governance setup you can operate with confidence: rules you understand, decisions you can test before they affect a running agent, and a record you can hand to a reviewer. Each guide assumes you have an agent in front of you and want governance on its tool calls, not a tour of features.

Two surfaces are covered throughout the documentation, and the guides note which one applies to each capability:

• **Qortara Governance** is the open-source sidecar (Apache-2.0, alpha v0.2.0). You can install it and run a governed agent today with `pip install qortara-governance-langchain`. Nothing here requires an account, and it is the free Developer tier.
• **Qortara Cloud Governance** is the hosted control plane. It is pre-launch and has not been deployed. Where a guide references a hosted endpoint or a centralized capability (centralized policy packs, server-side versioning, the evaluation API), it describes the pre-launch design, not a running service.

The two surfaces share one decision model: action plus resource pattern plus effect plus conditions, with deny always winning. If you author against the sidecar today, the concepts carry over to the hosted plane unchanged, so nothing you learn now is throwaway.

Available guides

• [Policy Authoring](/docs/guides/policy-authoring): the most complete guide in this section. It covers the sidecar YAML profile you can use today and the hosted JSON policy-pack format, the rule grammar (`action`, `resource_pattern`, `effect`, `conditions`), the condition operators (`require`, `unless`, `min_trust_score`, `time_window`, `max_rate`, `metadata_match`), five built-in templates you can copy, versioning, and how to test a policy before it affects a running agent.

More guides will be added here as they are written. The list above is the current set, not a roadmap.

What the authoring guide covers in depth

Policy Authoring is worth a closer look because most day-to-day governance work happens there. It walks through:

• **The sidecar YAML profile** you can run today: a named profile of ordered `allow` and `deny` rules with `when` clauses, selected in code when you construct your governed agent. A denied tool call raises rather than executing.
• **The hosted JSON policy-pack format** (pre-launch): the same allow/deny/condition model expressed as JSON and managed centrally through a REST API, with server-side versioning and a tamper-evident history.
• **The rule grammar:** `action`, `resource_pattern` (glob-style, so `customers/*/pii` matches `customers/12345/pii`), `effect`, and optional `conditions`.
• **The condition operators:** `require` and `unless` for capabilities, `min_trust_score`, `time_window`, `max_rate`, and `metadata_match`. Trust scores and cross-organization context are richest on the hosted plane; the sidecar evaluates the same operators against the context available locally.
• **Five copyable templates:** restrict PII access, restrict financial operations, business-hours-only exports, rate-limited API access, and a cross-org trust gate.
• **Versioning and testing:** how to test a policy with a dry-run evaluation (hosted) or a test case (sidecar) before it affects a running agent, and how to keep history in version control.

Where to start

If you are starting from scratch, this is the path that wastes the least time.

1. Read [Getting Started](/docs/quickstart) to install the sidecar and run a governed agent end to end.
2. Skim [Policy Enforcement](/docs/concepts/policy-enforcement) so you understand the allow, deny, and verify decision model before you write rules that produce those decisions.
3. Work through [Policy Authoring](/docs/guides/policy-authoring), starting from a copied template, and use the testing section to confirm a policy behaves before it touches a live agent.
4. When you are ready to wire governance into your framework specifically, follow the [LangChain integration guide](/docs/integrations/langchain).

A guiding principle: start narrow

Start narrow. Write explicit policies for the highest-risk tool categories first (PII access, financial operations, external writes), then widen coverage once you can see decision telemetry. A small policy set that you understand and test beats a broad one that nobody can reason about. Two practices reinforce this throughout the authoring guide:

• **Deny-by-default.** Begin with a catch-all deny and open up specific tools and resources as you confirm the agent needs them. An empty or overly permissive policy set governs nothing.
• **Fail closed.** If the decision point cannot reach a verdict, the safe default is to block the governed action rather than let it through ungoverned. Author and operate your policies so a denied result can never quietly become a permissive one.

Where to go next

• [Policy Enforcement](/docs/concepts/policy-enforcement): how runtime decisions are made and why pre-execution interception matters.
• [Compliance Evidence](/docs/concepts/compliance-evidence): how the decisions your policies produce become audit-ready records.
• [LangChain Integration](/docs/integrations/langchain): the complete sidecar setup for LangChain and LangGraph agents.
• Stuck on a policy or an integration? Email support@qortara.com.