Policies and enforcement

Policies turn risk, configuration, and product state into decisions such as allow, deny, block, or require approval. Ethen uses those concepts in several product families, but no single platform-wide policy engine is proven to cover every route, tool, provider, or workflow.

This page explains the policy model that can be documented today, how to locate the enforcement point, and which exception and evidence behaviors remain unresolved. The /policies route is an approved product surface; route existence alone does not establish complete enforcement.

Policy model

A policy evaluates a defined input and returns a decision that another component must enforce. Inputs can include the requested action, actor, resource, provider, risk class, product state, or project configuration. Known decision language includes allow, deny, requires_approval, human_required, and blocked.

These terms are related but not identical. deny rejects the operation. blocked can represent a product or readiness state that prevents progress. requires_approval and human_required indicate that execution must pause until a supported decision is recorded.

The effective policy is the combination of the decision logic and the code that reacts to it. A type or UI badge can describe a decision without proving that an external action is halted.

Decision vocabulary

Use decision terms consistently. allow means the policy does not stop the supported operation at that point. deny is an explicit negative decision. requires_approval or human_required pauses the action for a supported reviewer decision. blocked can describe a policy outcome or a broader readiness state, so the reason should accompany it.

Do not translate all negative states into “denied.” A missing credential, unavailable provider, disabled feature, or unsupported action may be blocked without being prohibited by policy. That distinction changes remediation: configuration can resolve setup failure, while a policy denial requires a policy or request change.

A policy result should not be used as proof that execution occurred. It describes the gate, not the downstream provider or tool outcome.

Policy ownership

Every production policy should have an owner who can explain its purpose, affected resources, decision vocabulary, and change process. A rule without an owner can remain active after the underlying risk or product behavior changes.

Version or date the policy configuration where the product supports it. If versioning is unavailable, preserve the relevant configuration during investigations so a later edit does not obscure the decision that applied at the time.

Policy documentation should name the protected outcome in plain language. A rule called “high risk” is not enough unless readers can determine which actions enter that class and what decision follows.

Scope

Policy scope should identify the product, route, action, resource, and environment to which a rule applies. A Sentinel repository review, Gateway provider request, Workflow Agent proposal, and Studio generation job can expose different inputs and side effects.

Do not assume that a rule shown on /policies automatically governs every product. Confirm the route or runtime that consumes the decision. Project-specific policy routes can be referenced as patterns such as /projects/[projectId]/policies, but a fabricated project ID must not be placed in a product link.

Broad rules are easier to state than to enforce safely. Prefer a narrow resource and action boundary when the ownership model is unresolved.

Scope dimensions

Define the smallest practical combination of:

• actor or caller type;
• product and route;
• action or tool;
• project or resource;
• provider or external destination;
• data class;
• risk or approval class;
• environment or deployment.

For example, allowing one project to invoke a text model through Gateway is narrower than allowing every project to use every provider. Requiring approval for a patch proposal is different from requiring approval to inspect a Sentinel finding.

The unresolved organization model makes broad organization-level scope especially risky. Use project and resource boundaries only where the server and store actually enforce them.

Avoid accidental expansion

A new product route, provider, model, or tool should not inherit a policy automatically unless the enforcement code and owner explicitly include it. Broad pattern matching can create either unexpected access or unexpected denial.

Test scope with both intended and out-of-scope resources. A project policy should not govern another project merely because their route names are similar, and a provider rule should not be assumed to cover a local runtime.

Evaluation

Evaluation should occur before the protected side effect. The evaluator needs enough trusted context to distinguish the actor, requested action, target resource, and relevant configuration. Client-provided labels should not substitute for server-derived ownership.

A reliable decision is deterministic for the same inputs unless the policy explicitly depends on changing state. Record the rule or policy identifier where available, the evaluated input class, the result, and any reason that is safe to expose.

Current products do not establish one universal evaluation schema. Avoid publishing field names or rule ordering beyond what the specific product implements.

Trusted context

The evaluator should derive identity, project ownership, and current configuration from trusted server state. A client may request an action, but it should not be able to declare itself an administrator or choose a different owner by changing an identifier.

Policy order can affect outcomes when several rules apply. No universal ordering contract is documented, so product pages should describe only their implemented behavior. If a denial and approval-required rule can both match, the runtime needs a deterministic precedence before the result is suitable for production.

When policy data cannot be loaded, the route’s failure behavior is part of the control. Record whether it stops safely, proceeds, or returns setup required.

A reviewer should also verify that time-sensitive inputs, such as provider readiness or project ownership, are evaluated close enough to execution that stale state cannot silently authorize the wrong path.

Enforcement

Enforcement is the point where the decision changes behavior. An allow decision can continue to the provider or runtime. A denial should stop before the side effect. An approval-required outcome should pause rather than simulate a completed action.

Review failure paths as well as the successful path. If policy storage is unavailable, decide whether the route fails closed, fails open, or becomes setup required. Missing-row and backend-readiness behavior is especially important for budget and policy checks.

Platform-wide coverage remains unverified. Document the exact product boundary instead of saying that “all Ethen actions are policy controlled.”

Verify the side-effect boundary

Test enforcement with an action that would create an observable effect but uses non-sensitive data. A denied request should not reach the provider or modify the resource. An approval-required request should remain pending. An allowed request can proceed but may still fail for authentication, entitlement, or provider reasons.

Inspect both the user-visible state and the underlying provider or store. A disabled button is not sufficient if the API can still be called. Conversely, a provider failure after an allow decision does not mean the policy failed.

Document the enforcement owner for each product. Without that mapping, “policy protected” is too broad to audit.

Enforcement failure modes

Policy enforcement can fail because the rule store is unavailable, identity or resource context is missing, the evaluator returns an unknown state, or the caller bypasses the protected interface and invokes another route. Each failure needs an explicit response.

For high-impact actions, prefer a safe blocked or setup-required state when the decision cannot be established. If a route intentionally fails open for availability, document that choice and limit the data or side effect accordingly.

Exceptions

An exception narrows or overrides a policy for a defined reason and duration. No central exception-management workflow is established, so do not invent request forms, automatic expiry, approver roles, or an organization-wide registry.

Where an exception is operationally necessary, record the affected action, resource, requester, reason, approving authority, start and end conditions, and compensating controls outside the product if needed. Avoid changing a general rule when a narrowly scoped configuration can address the case.

An exception should not bypass a legal, provider, or authorization boundary. A policy override cannot create access the underlying account or route does not possess.

Temporary exception record

Until a product implements a durable workflow, an external exception record should include the exact rule, action, resource, requester, approver, reason, start, expiry or completion condition, and compensating control. Review it when the condition ends.

Avoid permanent “temporary” exceptions. If a recurring need is legitimate, update the policy through an approved change process rather than relying on an undocumented override.

An exception cannot make an unavailable feature executable, grant a provider entitlement, or remove a legal obligation.

Review and closure

An exception should be reviewed when its owner, resource, provider, or business reason changes. At closure, remove the override, test the ordinary policy path, and record any residual configuration.

If the exception became permanent because the policy was wrong, update the policy and document the decision. Leaving an unowned override active makes later enforcement results difficult to explain.

Evidence

Policy evidence may include the decision, actor, resource, reason, rule reference, timestamp, approval state, and request or trace identifier. The record is useful only when its source and persistence are known.

Current audit and approval surfaces have sample, fixture, preview, or persistence limitations. A displayed policy outcome should not be called immutable or compliance grade. If the protected action has an external provider identifier, keep that identifier with the Ethen-side decision for investigation.

Use evidence to explain why an action proceeded or stopped. Do not treat an absent record as proof that no evaluation occurred unless the product contract requires a record and the store is verified.

Correlating a policy decision

Where the runtime supplies identifiers, connect the policy outcome to the request, proposal, approval, run, provider attempt, or resulting artifact. The chain should show what was requested, what decision was made, and what happened afterward.

Absence of an audit entry is not reliable proof that no decision occurred because durable ingestion is incomplete. Use the closest product record and label fixture or preview data accurately.

For a disputed outcome, preserve the policy configuration and relevant resource state from the time of evaluation. A later rule change can make the current configuration an inaccurate explanation of the earlier result.

Policy reports should distinguish configuration from observed enforcement. A rule definition shows intended behavior; a correlated denied or approval-required request shows that one execution path applied it. Both are useful, but neither alone proves complete product coverage.

Record untested routes and action classes explicitly so a later review does not interpret silence as assurance.