Granular Policy Engine

High-Level Overview

Iron Book’s policy engine provides fine-grained, attribute-based access control (ABAC) for AI agents. Rather than coarse “allow/deny” roles, policies consider rich agent attributes (from their trust profile) and context on each request.

This allows precise rules like “Agent X can query the finance DB only for customers in region EU if it holds a ‘EuropeanRegulator’ credential, and only between 9am–5pm UTC.”

Such dynamic policies ensure least-privilege and compliance filters (e.g. blocking access to EU data by a non-privacy-certified agent).

Technical Architecture

Policy Definition & Storage

Policies are expressed in a declarative language (e.g. JSON or Rego) and stored in Iron Book’s Policy Repository. They reference agent attributes (from VCs or trust profile), resource labels, actions, and environmental conditions. For example:

package ironbook.access

default allow = false

allow {
  input.agent.attributes.role == "finance_bot"
  input.request.action == "query"
  input.resource.label == "internal_finance_data"
  time_in_range(input.request.time, "09:00", "17:00")
  credential_verified(input.agent, "GDPRTrainingCert")
}

Policy Enforcement Points (PEPs)

Embedded in adapters and middleware, PEPs intercept agent requests and consult the policy engine. For web APIs, this might be an HTTP middleware. For agent-to-agent protocols (A2A), Iron Book’s middleware intercepts calls. Each PEP gathers the agent’s current attributes (via attached VCs or Identity Service) and the request details, then queries the Policy Decision Point (PDP).

Policy Decision Point (PDP)

The PDP evaluates rules in real time. It can call out to external Policy Information Points (PIPs) – e.g. to fetch latest device posture or environmental risk scores. The PDP returns a decision (allow/deny or obligations).

Fine-Grained Controls

The engine supports hierarchical policies and obligations. For instance, a policy may allow access only if a risk threshold is met, or may trigger an obligation such as “log this access and require manager approval.” Iron Book can enforce obligations (e.g. multi-step approval) as needed.

Dynamic Updates

Administrators can update policies on-the-fly. Iron Book supports versioning and immediate rollout. For critical changes, it can “pulse” the policy update to all PEPs instantly.

Developer Integration (Example)

Administrators manage policies via YAML/JSON or a web console. A sample policy in JSON might look like:

{
  "PolicyName": "FinanceDataAccess",
  "Effect": "Allow",
  "Actions": ["query", "export"],
  "Resources": ["db://finance/*"],
  "Conditions": {
    "StringEquals": {
      "agent.role": ["finance_bot"],
      "agent.region": ["EU"]
    },
    "NumericLessThanEquals": {
      "agent.trustScore": 80
    }
  },
  "Obligations": {
    "log": true
  }
}

When an agent makes a request, Iron Book’s SDK packages the agent’s current attributes and sends them to the policy engine. The engine returns “Allow” or “Deny”; if allowed with an obligation (e.g. log the event), the SDK handles it accordingly.

Compliance & Standards Mapping

Granular policies enable precise enforcement of regulatory access rules:

Standard	Iron Book Compliance
PCI DSS	Calls for role-based and need-to-know access. Fine-grained policies ensure that cardholder data access is strictly limited (e.g. agents can only read payment info through monitored APIs).
GLBA	Requires controlling access to nonpublic personal information. Iron Book policies can enforce rules such as “Only finance-approved agents can view loan application data,” meeting GLBA’s safeguarding rule.
HIPAA	Requires role-based access and auditing. Policies can restrict PHI queries to agents with specific healthcare roles/credentials, and log every access (see section 4).
SOX/SOC 2	Dictate that only authorized processes access financial records. Dynamic policies (with approval steps) help demonstrate segregation of duties and least privilege for audits.
ISO 42001	Demands risk management controls. The policy engine can encode risk-based rules (e.g. higher risk agents require extra controls).
GDPR	Data access should respect consent and data categories. Policies can enforce e.g. “No EU-citizen data may be processed by agents lacking a GDPR training credential,” aligning with GDPR’s data protection requirements.

IAM Interoperability

The policy engine can consume identity claims from Azure AD or AWS Cognito. For instance, if a user’s Azure AD token is exchanged for an agent operation, policies can reference Azure claims (like user’s group or AAD device compliance status) alongside Iron Book’s agent credentials.

Conversely, Iron Book can inject policy decisions into external IAM systems: e.g., on Azure, a custom policy can call Iron Book’s API to get an agent’s access decision before allowing or denying.

Iron Book also supports translating its policies into standard formats: for example, exporting OPA policies to AWS IAM Conditions for integration with AWS resource policies, or to XACML for legacy systems. In practice, this means an agent authenticated via OAuth2 (with an Iron Book-issued JWT) can be evaluated by enterprise systems using Iron Book’s policy decisions as input.