Install Jentic One Beta

Connect the Open Policy Agent (OPA) REST API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Open Policy Agent (OPA) REST API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fopenpolicy.local%2Fopenpolicy" | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fopenpolicy.local%2Fopenpolicy" | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Open Policy Agent (OPA) REST API.

Upload, retrieve, and delete Rego policy modules by ID

Push and read JSON data documents at arbitrary paths under /v1/data

Evaluate an ad-hoc Rego query against the loaded policies and data

Run partial evaluation via /v1/compile to produce residual queries

Probe instance health via the /health endpoint for readiness checks

GET STARTED

Start building with Open Policy Agent (OPA) REST API

Explore with Jentic One

View OpenAPI Document

Use Cases

Patterns agents use Open Policy Agent (OPA) REST API for, with concrete tasks.

★ Externalised authorization for microservices

A microservice delegates authorization decisions to OPA by POSTing the request context to /v1/data/{path} and reading the allow result, instead of embedding rules in code. This keeps policy changes out of service deploys and centralises audit, particularly useful when many services share the same authorization model.

PUT a Rego policy under /v1/policies/rbac, then POST input to /v1/data/rbac/allow and read the result field.

Kubernetes admission control via OPA

An admission controller calls OPA to decide whether a Kubernetes resource creation is allowed, based on namespace, labels, and image registry policy. OPA's /v1/data path returns a structured allow/deny decision with reasons that the controller surfaces back to kubectl.

POST the admission review payload to /v1/data/kubernetes/admission and parse the deny array from the response.

Partial evaluation for SQL filter generation

An application uses OPA's /v1/compile endpoint to perform partial evaluation, turning a high-level access policy into a residual query that can be folded into a database WHERE clause. This pushes row-level filtering down to the data layer while keeping the rules declarative.

POST a compile request to /v1/compile with the user query and unknowns, then translate the residual into a SQL WHERE fragment.

Agent-driven policy management through Jentic

An AI platform agent that maintains authorization rules across environments calls OPA via Jentic to deploy and verify Rego policies. Jentic exposes the policy and data endpoints as discoverable tools so the agent can promote a policy from staging to production with a single tool call.

Search Jentic for 'upload a Rego policy to OPA', load the PUT /v1/policies/{id} operation, and deploy a new policy module.

Key Endpoints

16 endpoints — jentic publishes the only available openapi specification for open policy agent (opa) rest api, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

PUT

/v1/policies/{id}

Upload or replace a Rego policy module

GET

/v1/policies/{id}

Retrieve a policy module by ID

POST

/v1/data/{path}

Evaluate a policy decision at a data path

POST

/v0/data/{path}

Evaluate input-only data with v0 semantics

POST

/v1/query

Run an ad-hoc Rego query

POST

/v1/compile

Run partial evaluation

GET

/health

Check instance health

PUT

/v1/policies/{id}

Upload or replace a Rego policy module

GET

/v1/policies/{id}

Retrieve a policy module by ID

POST

/v1/data/{path}

Evaluate a policy decision at a data path

POST

/v0/data/{path}

Evaluate input-only data with v0 semantics

POST

/v1/query

Run an ad-hoc Rego query

POST

/v1/compile

Run partial evaluation

GET

/health

Check instance health

Why Jentic?

What agents get from Jentic-routed access to this vendor.

Setup

Wiring the Open Policy Agent REST API by hand means pointing at your local OPA host, framing Rego policy uploads and data documents correctly, and building the query and compile request bodies yourself. Through Jentic you install once, import the Open Policy Agent API from the API Directory, and your agent calls it.

Permission scoping

OPA puts the policy id in the URL path (/v1/policies/{id}), so a rule can pin your agent to one policy: it can read that policy and nothing else. You choose the operations it may call, so writes like uploading a policy or evaluating data are not included unless you add them.

Credential isolation

Any network credential your OPA deployment sits behind, such as a proxy or mTLS front end, is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.

Intent-based discovery

Agents search Jentic by intent such as 'upload a Rego policy' or 'evaluate an authorization decision', and Jentic returns the matching policies, data, query, or compile operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

FAQs

Specific to using Open Policy Agent (OPA) REST API through Jentic.

Why is there no official OpenAPI spec for Open Policy Agent (OPA) REST API?

The OPA project does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Open Policy Agent (OPA) REST API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

What authentication does the Open Policy Agent API use?

OPA's REST API exposes no built-in authentication scheme in this spec - it is intended to run as a sidecar or local service trusted by the calling process. In production, deployments typically place OPA behind mTLS or a reverse proxy. Through Jentic, network credentials for the proxy stay in the vault rather than in the agent's prompt.

Can I evaluate a Rego policy decision via the API?

Yes. POST input data to /v1/data/{path} where {path} matches the policy's package, and OPA returns the evaluated result. For ad-hoc queries that don't map to a stored policy, use POST /v1/query instead.

What are the rate limits for the Open Policy Agent API?

OPA runs in-process or as a local sidecar, so there is no central rate limit - throughput is bounded by the host's CPU and the cost of the specific Rego rules being evaluated. Profile policies under load rather than relying on a vendor quota.

How do I deploy a new Rego policy through Jentic?

Run pip install jentic, search 'upload a Rego policy to OPA', load the PUT /v1/policies/{id} operation, and execute it with the policy id and Rego module body. Jentic handles the request shaping and returns the parsed response.

What's the difference between /v0/data and /v1/data?

The v1 path expects an input field wrapping the request and returns a structured result document, while v0 takes the input directly and returns the evaluated result without a wrapper. v1 is the modern surface; v0 is retained for backward compatibility with early OPA integrations.

Can I limit what my agent is allowed to do with the Open Policy Agent API?

Yes. Because you run Jentic One yourself, your own rules decide which OPA operations and credentials the agent may use, and it can only call what you list. Since OPA puts the policy id in the URL path at /v1/policies/{id}, you can pin the agent to a single policy and grant read-only access to it. Write operations like uploading a policy with PUT /v1/policies/{id} or evaluating data at /v1/data/{path} are excluded unless you explicitly add them.

Open Policy Agent (OPA) REST API

Name: Open Policy Agent (OPA) REST API
Brand: Open Policy Agent (OPA) REST API
Availability: InStock

Agent-ready OpenAPI document · curated by JenticSecurityCompliancenone16 EndpointsREST

Know of an official OpenAPI document? Contribute it →

For Agents

Upload Rego policies, push policy data, and evaluate authorization queries against a running Open Policy Agent instance.

Use for: Upload a new Rego policy that allows admin users to delete records, Get the current policy with id 'rbac' from OPA, Push a fresh roles dataset to /v1/data/roles, Evaluate whether user alice is allowed to read resource X

Not supported: Does not handle user authentication, secret storage, or audit log shipping - use for Rego policy management and authorization decisions only.

Jentic publishes the only available OpenAPI specification for Open Policy Agent (OPA) REST API, keeping it validated and agent-ready. OPA is a general-purpose policy engine that lets services delegate authorization, admission, and configuration decisions to declarative Rego policies. The REST API exposes endpoints to upload and remove policies, push and query data, evaluate ad-hoc queries, and compile partial-evaluation results, supporting cloud-native authorization patterns across Kubernetes, microservices, and CI pipelines.

Jentic One on Github View OpenAPI Document

Connect the Open Policy Agent (OPA) REST API to your agent

Capabilities

Start building with Open Policy Agent (OPA) REST API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs

Open Policy Agent (OPA) REST API