Compatibility and coverage

Your application uses an SDK to talk to its sidecar. Those two components need to work together. You also need to know which tools actually use them.

These are separate questions. Compatibility means the installed components can exchange the required requests and reports. Coverage means the application's real operations pass through the checks. Successfully installing a compatible SDK does not automatically protect the application's other tools.

Use this page when choosing an integration or preparing an upgrade. The task is to record the combination you will run and verify it with safe requests.

Choose the SDK for your application

Run the sidecar with Docker, the recommended setup, or use a native binary. Both run the same local decision process.

Record the components you will run

The installation guides use SDK 0.1.1 from npm, PyPI or Go package documentation. The sidecar has native release 0.1.0. The Docker guide builds its image from source.

Keep the installed SDK version and the sidecar archive version, or the source commit and image digest when building it, with your deployment notes. An image digest identifies the exact container image, rather than a tag that can later point elsewhere.

Use a combination verified together. Review changes before upgrading either component independently. For OpenShell, also record the upstream version and policy used; its guide describes the reviewed 0.1.6 integration.

Check the protected operation

In a safe application or provider test account:

1. Try an allowed request in Enforce. Inspect its call and result checks, execution start and reported completion.
2. Try a denied request. Check the effect record or provider account to establish that the operation did not run.
3. Try a request needing approval. Review it, then continue the saved request through the application's approval flow.
4. Check reporting failure and recovery. Confirm that permission saved only in a local queue cannot start Enforce execution. Use the recovery guide to test a lost response without duplicating a business effect.
5. Review other routes to the same action. Follow the security guide, including credentials, tools and network paths that could bypass the protected application.

Expected result: you know which installed versions were exercised, which operations were protected and what happened when a check or dependency failed. Keep gaps visible to the team operating the application. When checking a real provider effect, inspect its actual record separately from the application's report to AuthRail.

More about protocol versions and upgrades

The signed bundle and local evaluation use formatVersion: 1. This names a message format. It does not by itself establish compatible recovery behavior or coverage of every tool.

The sidecar's packaged COMPATIBILITY.md records its protocol requirements and source-level verification history. Use the installation guides for published package versions; a historical source check does not prove an independently upgraded combination works. Its shared conformance/v1 examples check that implementations encode signed requests and interpret decisions consistently. Keep those references, the server contract and any OpenShell artifacts with the deployment review. Use the supported SDKs rather than rebuilding their signing and recovery logic.

Before replacing a running instance, preserve the entire sidecar state set, application recovery records, keys and pending approvals. Verify the new combination in a safe installation first. Review coverage again when changing sandbox access, provider accounts, processing handlers or network permissions. A missing handler or unavailable required isolation cannot be treated as a passing Enforce check.