# 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.