Concepts

This section explains the ideas behind Qortara governance: what each control does, why it matters for an agent platform, and how it behaves at runtime. AI agents do not just answer questions; they call tools, read records, move money, and write to systems your business depends on. The moment an agent can act, governance stops being a logging concern and becomes a control concern. These pages give a developer or security engineer a clear mental model of how Qortara exercises that control before you reach for an API reference or wire up an integration.

The thread running through every concept here is simple: evaluate an action against policy before it happens, record the decision in a form you can later verify, and make that record useful to the people and systems that need it. Enforcement produces the record. Trust attestation makes a slice of that record portable across organizations. Saga verification checks that an authorized action actually did what it claimed. Webhooks carry the activity out to your operations tooling, and compliance evidence shapes the same activity into something an auditor can review. Each idea builds on the one before it.

Qortara ships in two forms, and the concept pages are explicit about which form a given capability belongs to.

• **Qortara Governance** is the open-source sidecar (`pip install qortara-governance-langchain`, Apache-2.0, alpha v0.2.0). It runs in your own process and enforces policy on the dispatch path of an agent's tool calls. It is self-serve and available today, and it is the free Developer tier.
• **Qortara Cloud Governance** is the hosted control plane: a Cedar-based policy decision point, cross-tenant evidence, saga verification, webhooks, and compliance reporting. It is pre-launch and has not been deployed. Where a page describes a hosted capability, it says so and uses "designed to" framing rather than present-tense availability.

A further capability, the **Trust Mesh** (branded Qortara Trust Federation), refers to the planned bilateral cross-organization trust operator. The underlying portable trust attestation lifecycle (attest, look up, verify) exists today; the full federation operator is planned. The trust page draws that line carefully.

What this section covers

A suggested reading order

If you are new to Qortara, read these in order. They are written to build on each other.

1. Start with [Policy Enforcement](/docs/concepts/policy-enforcement). It is the foundation: the runtime decision point that returns allow, deny, or verify before an action runs, and the source of every governance record. Dispatch-path enforcement in the open-source sidecar is available today, so this is also the concept you can put into practice immediately.
2. Read [Trust Federation](/docs/concepts/trust-federation) next. It explains how an agent's governance history becomes a portable trust score and a signed attestation that another organization can verify with Ed25519. The attest, look up, and verify lifecycle is shipped; the bilateral Trust Mesh that automates cross-org exchange is planned.
3. Then [Saga Verification](/docs/concepts/saga-verification), which goes beyond "was the agent allowed" to "did the action produce the outcome it should have." This is a pre-launch hosted capability, so read it as the target design.
4. [Webhooks and Events](/docs/concepts/webhooks-events) shows how the activity above is delivered, signed and retried, into the systems your responders already watch. Also pre-launch (hosted).
5. Finish with [Compliance Evidence](/docs/concepts/compliance-evidence), which organizes the same governance activity into audit-ready material mapped to frameworks. Pre-launch (hosted), and explicitly not a certification.

How the pieces fit together

Policy enforcement is the foundation: every governed action produces a decision and a tamper-evident record. Trust attestations summarize an agent's history so other parties can reason about it without seeing your policy internals. Saga verification confirms that authorized actions actually did what they claimed and feeds positive or negative signals back into the trust score. Webhooks carry all of this activity out to the systems your team already watches, and compliance evidence organizes the same activity into a form an auditor can review.

A single thread of activity therefore serves several audiences at once. The same `policy_evaluation` that blocks an unauthorized PII read is the deny decision your responder sees in the SIEM, a line item in a SOC 2 access-decision log, and a signal that nudges the agent's trust score. You instrument enforcement once; the other concepts reuse what it produces.

Adopt incrementally

You do not have to adopt everything at once, and the availability split makes that natural. The sidecar gives you dispatch-path enforcement on its own, today, with no account: install it, point it at a policy pack, and your agent's tool calls are governed before they run. The portable trust attestation lifecycle is also available now. The remaining hosted capabilities (centralized evidence, saga verification, webhook delivery, fleet visibility, and the Trust Mesh) build on that same foundation and are designed to layer in as Qortara Cloud Governance becomes available. Building against the decision model now means the hosted pieces slot in later without reworking your agent.

A note on dependencies and naming

Qortara is independent. LangChain and LangGraph are trademarks of LangChain, Inc.; Qortara integrates with them but is not affiliated with them. None of these relationships imply endorsement.

Where to go next

• Ready to run a governed agent? Follow [Getting Started](/docs/quickstart) and the [LangChain integration guide](/docs/integrations/langchain).
• Ready to write rules? See [Policy Authoring](/docs/guides/policy-authoring).
• Working toward an audit? Start with [Compliance Evidence](/docs/concepts/compliance-evidence) and the [SOC 2 evidence guide](/docs/compliance/soc2).