Integrations

Qortara sits between two worlds. On one side are the agent frameworks where actions originate: LangChain and LangGraph agents deciding which tool to call. On the other side are the security and observability systems your team already lives in: the SIEM, the dashboards, the alerting. Integrations are how Qortara plugs into both. The goal is the same in either direction: evaluate an agent's actions against policy before they run, and get a durable, structured record of every decision into the systems your team already watches.

These two directions are also where Qortara's two product surfaces show up most clearly. The inbound side, governing tool calls, is the open-source sidecar and is available today. The outbound side, streaming governance events to your tooling, is delivered by the hosted control plane and is pre-launch. Read the availability note for each integration before you plan a rollout, because adopting the sidecar and adopting an outbound connector are decisions at different stages of readiness.

Available integrations

LangChain (Qortara Governance, open source, available)

The LangChain integration ships as the `qortara-governance-langchain` package. It installs a sidecar that hooks the framework's own dispatch methods (`BaseTool.invoke`, `BaseTool.ainvoke`, and LangGraph's `ToolNode.invoke`), evaluates each call against your policy pack, and blocks anything that is denied before the tool executes. Because it hooks dispatch rather than individual tools, it governs every tool the agent can reach, custom or built-in, without changes to your prompt or model.

This is the path you can adopt today: install it from PyPI, point it at a policy pack, attach it with `governance.install(executor)`, and run it self-serve under the Apache-2.0 license. No account required. Most teams start here, get dispatch-path enforcement working against a deny-by-default pack, then add an outbound connector once the hosted plane is available.

Start here: [LangChain integration guide](/docs/integrations/langchain).

Splunk (Qortara Cloud Governance, pre-launch)

The Splunk integration is webhook-based. Qortara Cloud Governance is designed to forward governance events to a Splunk HEC endpoint you register, where they land as structured JSON with the `qortara:governance` sourcetype, ready for SPL searches, dashboards, and CIM data models. Cloud Governance has not launched yet, so treat the Splunk guide as a reference for how the hosted platform is designed to work rather than as a description of a running service.

That said, much of the setup is on the Splunk side and you can do it now: the HEC token configuration, the `props.conf` field extractions and CIM field aliases, the example SPL searches, the recommended dashboards, and the event schema in that guide are accurate reference material you can review and prepare against today. The live event flow becomes available when Cloud Governance launches; until then the only step you cannot complete is registering the Qortara webhook destination.

Read more: [Splunk integration guide](/docs/integrations/splunk).

Planning a Splunk rollout while Cloud is pre-launch

Because the Splunk-side setup is independent of Qortara, you can get most of the way to a working integration before the hosted event flow exists. A reasonable sequence:

1. Create a dedicated `qortara` index in Splunk so you can tune retention separately from other data.
2. Create a HEC token (for example named `qortara-governance`) and confirm HEC is enabled with SSL on. Qortara is designed to refuse delivery to non-HTTPS endpoints.
3. Verify the token works with a manual test event so you know the receiving side is correct.
4. Add the `props.conf` field extractions and the CIM field aliases from the guide so events parse cleanly and participate in Splunk Enterprise Security data models.
5. Stage the example SPL searches and dashboard panels so they are ready the moment events begin to flow.

The only step you cannot complete until Qortara Cloud Governance launches is registering the Splunk HEC endpoint as a webhook destination in the Qortara portal. Everything else is real work you can finish now. See the [Splunk integration guide](/docs/integrations/splunk) for the exact commands and configuration.

How the two directions connect

The inbound and outbound integrations are two ends of one pipeline. The LangChain sidecar produces a `policy_evaluation` (and a matching signed `audit_event`) for every governed tool call. The Splunk connector is one designed destination for that same stream of events. The general mechanism behind any outbound connector is the hosted webhook system, which delivers signed, retried, at-least-once events to endpoints you configure. If you understand how the sidecar generates decisions and how webhooks deliver them, you understand how any future connector will behave. For the full event catalog and delivery contract, see [Webhooks and Events](/docs/concepts/webhooks-events).

Asking for another integration

The integrations catalog is still being validated against app-dev source-of-truth before more vendor pages are published, so the two connectors above are the current set rather than a roadmap. If you need a connector that is not listed, email support@qortara.com. Because outbound integrations are built on the standard webhook delivery contract, many destinations (Datadog, PagerDuty, Slack, or a custom backend) can be reached today in principle by pointing a webhook at them; the [Webhooks and Events](/docs/concepts/webhooks-events) page lists common patterns. Integrations are prioritized by customer demand.

Where to go next

• [LangChain Integration](/docs/integrations/langchain): the complete, available sidecar setup.
• [Policy Authoring](/docs/guides/policy-authoring): write the policy pack the sidecar evaluates.
• [Webhooks and Events](/docs/concepts/webhooks-events): the delivery contract every outbound connector is built on.