Policies & Governance

Highflame's governance model is built around typed Cedar policies, project-scoped administration, and runtime evidence captured across the platform. Instead of managing AI controls as ad hoc allowlists, prompt rules, and application-specific conditionals, the control plane gives you a shared policy layer that can be enforced by Shield, Firehog, and other runtime services.

Policy System

The policy foundation is provided by @highflame/policy package:

• Cedar schemas define the valid entity types, actions, and context keys

• generated types keep policy constants consistent across TypeScript, Go, Python, and Rust

• runtime services such as Shield evaluate those policies during enforcement

This allows policy changes to remain explicit, reviewable, and portable across products.

Schema-Backed Authoring

Policies in Highflame are not free-form text pasted into a single service. They are tied to service-specific schemas so authors can work against the right action model and context surface for the product they are configuring.

Today that includes schemas for areas such as:

• Guardrails for prompt, tool, file, and response enforcement

• Overwatch for code agent and IDE operations

In Studio, teams can work with Cedar-aware editors and policy builders that validate policies against those schemas before they are deployed.

What Governance Looks Like In Practice

In day-to-day use, governance in the control plane usually means:

• defining baseline guardrail policies that apply across a project

• layering stricter rules for higher-risk agents, tools, or environments

• controlling which MCP servers and tool operations are allowed

• validating changes before rollout instead of discovering syntax or schema errors at runtime

• investigating the exact policy and signal path behind a deny decision

Because policies are enforced against rich runtime context, teams can write rules that go beyond role checks. For example, a policy can depend on tool type, environment, detector score, MCP trust level, or whether earlier turns exposed sensitive data.

Governance Evidence

Governance is only useful if you can prove what the system decided. Highflame captures that evidence through Observatory and the runtime services:

• Shield returns determining policies and policy reasons for enforcement decisions

• observability events retain the signals and policy metadata that contributed to a decision

• sessions and traces preserve the surrounding execution context for later review

This gives security, platform, and compliance teams a concrete path from policy definition to runtime evidence, without relying on screenshots or manual log collection.

Working With Policies In Studio

Studio acts as the control surface for governance. Teams use it to:

• manage policies by product and project scope

• validate Cedar text against the correct schema

• inspect policy status and deployment state

• review policy-backed outcomes alongside runtime investigations

The result is a governance model that stays close to the actual execution path. Policies are authored centrally, enforced at runtime, and visible again during investigation.