Documentation

Getting Started

Stratium provides a unified control plane for ABAC authorization, entitlements management, and AI agent governance. This guide will walk you through initial setup and configuration.

Prerequisites

• An active Stratium account (SaaS) or deployed instance (on-prem)
• PAP and PDP services deployed with network connectivity
• API credentials configured in your environment
• The Stratium CLI or SDK installed

Quick Start

# Install the Stratium CLI
npm install -g @stratium/cli

# Initialize your project
stratium init

# Configure your first policy
stratium policy create --name "default" --type abac

First Policy (OPA)

The easiest way to get started is with an OPA policy:

{
  "name": "My First Policy",
  "effect": "allow",
  "language": "opa",
  "policy_content": {
    "rego": "package stratium.authz\n\ndefault allow = false\n\nallow {\n    input.subject.department == \"engineering\"\n    input.resource.owner == \"engineering\"\n}"
  }
}

First Entitlement

Grant users access to resources based on attributes:

{
  "name": "Engineering Database Access",
  "subject_attributes": { "department": "engineering" },
  "resource_attributes": { "resource_type": "database" },
  "actions": ["read", "write"]
}

Authentication Setup

Configure OIDC to integrate with your identity provider:

# config.yaml
oidc:
  issuer: "https://your-idp.com"
  client_id: "your-client-id"
  client_secret: "your-client-secret"

Policies

Stratium supports multiple policy formats. The policy engine evaluates access decisions in real time based on attributes, context, and organizational rules. All formats are normalized into a unified evaluation pipeline.

Supported Formats

• JSON — Simple, declarative rules with rich operators. Best for attribute-based decisions and quick prototyping.
• OPA / Rego — Advanced logic with iteration, comprehensions, and custom functions. Best for complex rules and data transformation.
• XACML 3.0 — OASIS standard with policy sets, combining algorithms, and obligations. Best for regulatory compliance (HIPAA, SOX, GDPR).

Policy Structure

{
  "id": "unique-policy-id",
  "name": "Human Readable Policy Name",
  "description": "What this policy does",
  "effect": "allow",
  "language": "json",
  "priority": 100,
  "enabled": true,
  "policy_content": {
    "conditions": {
      "subject": { /* subject conditions */ },
      "resource": { /* resource conditions */ },
      "action": { /* action conditions */ },
      "environment": { /* optional: env conditions */ }
    }
  }
}

Priority System

• 9000–10000 — Critical deny policies (e.g., suspended accounts)
• 5000–8999 — Security policies (e.g., clearance checks)
• 1000–4999 — Department and role policies
• 0–999 — General access policies

Deny policies override allow policies at the same priority level.

JSON Policies

JSON policies support a rich set of operators for flexible rule definition.

Operators

• $eq / $ne — Equals / not equals
• $in / $nin — In array / not in array
• $gt / $gte / $lt / $lte — Numeric comparisons
• $contains — Array contains value
• $regex — Regular expression match
• $resource.* / $subject.* — Cross-attribute references

Hierarchical Comparisons

For attributes with hierarchical values (e.g., security clearances):

{
  "subject": {
    "clearance": { "$gte": "$resource.classification" }
  }
}

// Hierarchy: UNCLASSIFIED < RESTRICTED < CONFIDENTIAL < SECRET < TOP-SECRET

Example: Multi-Condition Policy

{
  "name": "Sensitive Data Access",
  "effect": "allow",
  "language": "json",
  "priority": 1000,
  "policy_content": {
    "conditions": {
      "subject": {
        "clearance": { "$gte": "SECRET" },
        "training_completed": { "$eq": true },
        "department": { "$in": ["security", "legal", "compliance"] }
      },
      "resource": {
        "classification": { "$lte": "SECRET" }
      },
      "action": {
        "action_name": { "$eq": "read" }
      }
    }
  }
}

Example: Deny Policy

{
  "name": "Deny Suspended Users",
  "effect": "deny",
  "language": "json",
  "priority": 9999,
  "policy_content": {
    "conditions": {
      "subject": {
        "account_status": { "$eq": "suspended" }
      }
    }
  }
}

Testing Policies

POST /api/v1/policies/test
Content-Type: application/json

{
  "policy": { /* your policy */ },
  "evaluation_context": {
    "subject": { "clearance": "SECRET" },
    "resource": { "classification": "CONFIDENTIAL" }
  }
}

OPA / Rego Policies

OPA policies use the Rego language for advanced authorization logic with iteration, comprehensions, and custom functions.

When to Use OPA

• Complex logic with multiple nested conditions
• Iterating over arrays or sets
• Data transformation and filtering
• Policy composition and reuse

Example: Department + Clearance Check

package stratium.authz

default allow = false

allow {
    # User must be in engineering
    input.subject.department == "engineering"

    # Clearance must meet or exceed classification
    clearance_level[input.subject.clearance] >=
        clearance_level[input.resource.classification]
}

clearance_level := {
    "UNCLASSIFIED": 0,
    "RESTRICTED": 1,
    "CONFIDENTIAL": 2,
    "SECRET": 3,
    "TOP-SECRET": 4,
}

Example: Role-Based with Exceptions

package stratium.authz

default allow = false

# Admins can do anything
allow {
    input.subject.role == "admin"
}

# Managers can approve within their department
allow {
    input.subject.role == "manager"
    input.action == "approve"
    input.subject.department == input.resource.department
}

XACML Policies

XACML is an OASIS standard for enterprise-grade access control with policy sets, combining algorithms, obligations, and formal audit trails. Stratium supports XACML 3.0 and 2.0.

When to Use XACML

• Regulatory compliance requirements (HIPAA, SOX, GDPR)
• Enterprise governance with formal audit trails
• Policy sets with combining algorithms
• Obligations and advice mechanisms
• Interoperability with other XACML-compliant systems

Example: Basic XACML Rule

<Rule RuleId="engineering-read" Effect="Permit">
  <Target>
    <AnyOf>
      <AllOf>
        <Match MatchId="string-equal">
          <AttributeValue>engineering</AttributeValue>
          <AttributeDesignator
            Category="subject"
            AttributeId="department"
            DataType="string"/>
        </Match>
      </AllOf>
    </AnyOf>
  </Target>
  <Condition>
    <Apply FunctionId="string-equal">
      <Apply FunctionId="string-one-and-only">
        <AttributeDesignator
          Category="action"
          AttributeId="action-id"/>
      </Apply>
      <AttributeValue>read</AttributeValue>
    </Apply>
  </Condition>
</Rule>

Policy Best Practices

Design Principles

• Use descriptive names and descriptions — not “Policy 1”
• Break complex policies into multiple simpler policies
• Use cross-attribute references ($resource.project) instead of hardcoded values
• Set appropriate priorities using the priority system

Deployment Process

1. Create policy with "enabled": false
2. Validate syntax: POST /api/v1/policies/validate
3. Test with evaluation context: POST /api/v1/policies/test
4. Enable with low priority in non-production
5. Monitor access logs and adjust priority

API Reference

# Create policy
POST /api/v1/policies

# Update policy
PUT /api/v1/policies/{id}

# Delete policy
DELETE /api/v1/policies/{id}

# List policies
GET /api/v1/policies?language=json&enabled=true

# Validate syntax
POST /api/v1/policies/validate

# Test with evaluation context
POST /api/v1/policies/test

Entitlements

Entitlements define who can perform what actions on which resources. They work alongside policies to provide fine-grained access control.

Entitlements vs Policies

• Entitlements — Define access grants. Coarse-grained. “Engineering can read engineering docs.”
• Policies — Define access rules. Fine-grained. “Users with SECRET clearance can read CONFIDENTIAL docs during business hours.”

Both must pass for access to be granted: entitlements check broad eligibility, policies enforce specific rules.

Entitlement Structure

{
  "id": "unique-entitlement-id",
  "name": "Human Readable Name",
  "description": "What this entitlement grants",
  "enabled": true,
  "subject_attributes": {
    "department": "finance"
  },
  "resource_attributes": {
    "resource_type": "database",
    "owner": "finance"
  },
  "actions": ["read", "write", "query"],
  "conditions": {
    "time_restriction": { "start": "09:00", "end": "17:00" }
  }
}

Creating via CLI

stratium entitlement create \
  --subject "user:alice@example.com" \
  --resource "dataset:financial-reports" \
  --attributes '{"clearance": "confidential", "department": "finance"}' \
  --actions read,export

Common Patterns

Department-based access:

{
  "name": "Finance Department Database Access",
  "subject_attributes": { "department": "finance" },
  "resource_attributes": { "resource_type": "database", "owner": "finance" },
  "actions": ["read", "write", "query"]
}

Cross-department read access:

{
  "name": "Shared Reports Read Access",
  "subject_attributes": {
    "department": ["finance", "operations", "executive"]
  },
  "resource_attributes": { "resource_type": "report", "category": "shared" },
  "actions": ["read", "export"]
}

Contractor access with time limits:

{
  "name": "Contractor Limited Access",
  "subject_attributes": {
    "employment_type": "contractor",
    "project": "project-alpha"
  },
  "resource_attributes": { "project": "project-alpha" },
  "actions": ["read"],
  "conditions": {
    "valid_until": "2026-12-31",
    "time_restriction": { "start": "09:00", "end": "17:00" }
  }
}

Agent Authorization

The Agent Gateway authorizes AI agents acting on behalf of users. Every agent action is evaluated against user permissions, agent permissions, and delegation scope in a single compound decision.

Registering an Agent

stratium agent register \
  --name "finance-analyst-agent" \
  --provider anthropic \
  --trust-tier 2 \
  --allowed-tools "sql_query,report_generate" \
  --owner "finance-ops"

Trust Tiers

• Tier 0 — Unverified: Read-only, sandboxed, no external actions
• Tier 1 — Registered: Read + limited write, no external comms
• Tier 2 — Certified: Full read/write within delegation scope
• Tier 3 — Platform-trusted: System-level actions under system authority

Creating a Delegation

stratium delegation create \
  --agent-id "finance-analyst-agent" \
  --user "alice@example.com" \
  --purpose "quarterly-report" \
  --max-action-tier 2 \
  --classification-caps '{"commercial": "INTERNAL"}' \
  --ttl 15m

Compound Policy Evaluation

The policy engine evaluates: user_allowed AND agent_allowed AND delegation_allowed. All three must be ALLOW for the action to proceed.

Delegation Chains

When agents delegate to sub-agents, each hop in the chain must be a strict subset of its parent:

• Classification caps can only narrow
• Action tiers can only decrease
• Tools can only be removed, never added
• Max chain depth: 5 (configurable via DELEGATION_MAX_DEPTH)

Integration

Stratium integrates with your existing identity providers, databases, and secret managers.

OIDC / OAuth2

Connect your identity provider for SSO, centralized user management, and attribute synchronization. Stratium supports any OIDC-compliant provider.

Supported providers:

• Keycloak
• Auth0
• Okta
• Azure AD (Entra ID)
• Any OIDC-compliant provider

Configuration

# config.yaml
oidc:
  issuer: "https://auth.example.com"
  client_id: "stratium-app"
  client_secret: "${OIDC_CLIENT_SECRET}"
  redirect_uri: "https://app.example.com/callback"
  scopes: ["openid", "profile", "email"]

  # Attribute mapping
  attribute_mapping:
    department: "custom:department"
    clearance: "custom:clearance_level"
    role: "realm_roles"

Database

Stratium uses PostgreSQL for persistent storage of policies, entitlements, audit logs, user attributes, and configuration.

Configuration

# config.yaml
database:
  connection_string: "postgresql://stratium:${DB_PASSWORD}@localhost:5432/stratium?sslmode=require"

  # Connection pool
  pool:
    max_connections: 20
    min_connections: 5
    max_idle_time: "5m"

What’s Stored

• Policy definitions (JSON, OPA, XACML)
• Entitlement grants
• Audit logs (authorization decisions and admin actions)
• User attribute extensions
• Agent registrations and delegation records
• System configuration and metadata

Secrets Manager

Integrate with external secrets managers for centralized, auditable, and rotatable secret storage.

Supported Providers

• HashiCorp Vault — Token, AppRole, and Kubernetes auth
• AWS Secrets Manager — IAM role and access key auth
• Azure Key Vault — Service principal and managed identity auth
• Google Secret Manager — Service account and workload identity auth
• Kubernetes Secrets — Native K8s secret mounting

Example: HashiCorp Vault

# config.yaml
secrets:
  provider: "vault"
  vault:
    address: "https://vault.example.com:8200"
    auth_method: "approle"
    role_id: "${VAULT_ROLE_ID}"
    secret_id: "${VAULT_SECRET_ID}"
    secret_path: "secret/data/stratium"

Example: AWS Secrets Manager

# config.yaml
secrets:
  provider: "aws"
  aws:
    region: "us-east-1"
    secret_name: "stratium/production"

SDKs & Samples

Client libraries are available for Go, Java, Python, and JavaScript. All SDKs support policy evaluation, entitlement management, and agent authorization flows.

Go Client

import "github.com/stratium/sdk-go"

client := stratium.NewClient(stratium.Config{
    Endpoint: "https://api.stratium.dev",
    APIKey:   os.Getenv("STRATIUM_API_KEY"),
})

decision, err := client.Authorize(ctx, stratium.Request{
    Subject:  "user:alice",
    Resource: "dataset:financial",
    Action:   "read",
})

JavaScript Client

import { Stratium } from '@stratium/sdk';

const client = new Stratium({
  endpoint: 'https://api.stratium.dev',
  apiKey: process.env.STRATIUM_API_KEY,
});

const decision = await client.authorize({
  subject: 'user:alice',
  resource: 'dataset:financial',
  action: 'read',
});

Python Client

from stratium import StratiumClient

client = StratiumClient(
    endpoint="https://api.stratium.dev",
    api_key=os.environ["STRATIUM_API_KEY"],
)

decision = client.authorize(
    subject="user:alice",
    resource="dataset:financial",
    action="read",
)

Java Client

import io.stratium.sdk.StratiumClient;
import io.stratium.sdk.AuthzRequest;

StratiumClient client = StratiumClient.builder()
    .endpoint("https://api.stratium.dev")
    .apiKey(System.getenv("STRATIUM_API_KEY"))
    .build();

Decision decision = client.authorize(AuthzRequest.builder()
    .subject("user:alice")
    .resource("dataset:financial")
    .action("read")
    .build());

Sample Applications

• Go CLI Client — Command-line tool for policy-based authorization with OIDC authentication
• React Web App — Web application with attribute-based access control using the JavaScript SDK

# Clone the demo stack
git clone https://github.com/stratiumdata/stratium-agent-demo.git
cd stratium-agent-demo
make quickstart
make demo-flow-all
make demo-flow-chain
make demo-flow-mcp-codex
make demo-flow-mcp-claude

Resources

Zero Trust Architecture

• NIST SP 800-207 — Zero Trust Architecture
• CISA Zero Trust Maturity Model — Framework for implementing Zero Trust
• NSA Zero Trust Security Model — Zero Trust guidance from NSA

Attribute-Based Access Control

• NIST SP 800-162 — Guide to Attribute-Based Access Control
• OASIS XACML — XACML Technical Committee and standard
• Open Policy Agent — Policy-based control for cloud native environments

Compliance & Standards

• NIST Cybersecurity Framework — Critical infrastructure cybersecurity
• ISO/IEC 27001 — Information security management systems
• FedRAMP — Federal Risk and Authorization Management Program