Policies
Policies are the authorization rules. Each policy defines who can do what on which resources.
Policy structure
A policy has:
| Field | Description |
|---|---|
| Name | Human-readable identifier |
| Effect | ALLOW or DENY |
| Actions | What actions this policy covers — a subset of the actions defined on the resource type (e.g., read, write) |
| Resource type | Which resource type this policy applies to — covers every instance of that type, including ones created in the future |
| Resources | Specific resource instances this policy applies to — use when you need per-resource granularity instead of type-wide coverage |
| Priority | Numeric priority (0–100). When multiple policies match, the highest-priority one takes precedence. Default: 50 |
Policy assignment
Policies don't do anything on their own — they need to be assigned. You can assign a policy to:
- A subject directly — Only that specific subject gets the policy (direct access)
- A role — All subjects with that role get the policy (RBAC)
DENY policies
DENY policies override ALLOW policies when the DENY has equal or higher priority. A low-priority DENY does not beat a high-priority ALLOW.
Use DENY policies for:
- Revoking access for specific subjects
- Blocking access to sensitive resources
- Temporary access restrictions
ABAC conditions
Policies can include attribute-based conditions that compare subject, resource, or context attributes at evaluation time. This turns a simple RBAC policy into a fine-grained ABAC policy.
See ABAC Conditions for full syntax and examples.
Example: allow read only when the subject and resource are both in the engineering department:
{
"conditions": {
"subject_attrs": [
{ "attr": "department", "op": "==", "value": "engineering" }
],
"resource_attrs": [
{ "attr": "department", "op": "==", "value": "engineering" }
]
}
}
Guardrails
Guardrails are optional constraints on when a policy applies. Enable them without rewriting the policy itself:
| Guardrail | Effect | Enforced by |
|---|---|---|
| Time window | Policy only applies within a configured time range | Vengtoo (system clock) |
| IP allowlist | Policy only applies when context.ip matches an allowed range | Caller-reported |
| Geo restriction | Policy only applies when context.geo matches an allowed country code (ISO 3166-1 alpha-2) | Caller-reported |
| MFA required | Policy only applies when context.mfa_verified is true | Caller-reported |
| Subject attribute | Policy only applies when the subject has a matching attribute | Caller-reported |
| Resource attribute | Policy only applies when the resource has a matching attribute | Caller-reported |
| Context attribute | Policy only applies when a context.* value matches (e.g., env, api_version, session_risk) | Caller-reported |
Guardrails are additive — enable multiple guardrails on one policy and all must pass.
Caller-reported guardrails are evaluated against context your backend provides. The security comes from the fact that only authenticated callers (API key or client credentials) can call Vengtoo — end users never interact with Vengtoo directly.
Geo-restriction evaluates the country code your backend passes as context.geo. Derive it from the request IP in your backend before calling Vengtoo.
Configure guardrails from the policy detail page in the console, or via the Management API.
Missing context values fail closed
If a guardrail references a context key — context.ip, context.geo, context.mfa_verified, a custom context.env, or any other key — and the evaluation request does not include that key, the guardrail fails closed: the policy does not apply, and access is denied.
This is intentional. Vengtoo treats an unverifiable condition as a failing condition; permitting access based on an absent value would undermine the guardrail entirely.
The failure is silent: a "decision": false response from a missing context key looks identical to a genuine access denial. If you see unexpected denials on a policy that has guardrails, verify that every context key the guardrail expects is present in your evaluation request. The Context Trust Model page lists the standard keys and where to source each one.
Policy status
Policies have a status lifecycle:
| Status | Meaning |
|---|---|
| Active | Evaluated normally |
| Inactive | Exists but skipped during evaluation |
Use inactive status to temporarily disable a policy without deleting it. Toggle status from the policy list or detail page.
A policy with no resource or resource type assignments matches nothing and is shown as Draft in the dashboard — this is not a status you set, it is derived automatically. Assigning a resource activates the policy.
A policy with resource assignments but no subject assignments (no direct subjects, no role bindings, no ABAC conditions) is shown as Orphaned in the dashboard. Like draft, this is derived — it means the policy has targets but nobody can be matched by it.
Examples
| Policy | Effect | Actions | Resource type | Assigned to |
|---|---|---|---|---|
| editors-can-read-write | ALLOW | read, write | document | editor role |
| block-contractor-delete | DENY | delete | document | Frank (subject) |
| deployers-write-hours | ALLOW | write | config | deployer role (with time-window guardrail) |
| agent-read-only | ALLOW | read, list | mcp_tool | agent-readonly role |
Related
- ABAC Conditions — Full condition syntax reference.
- Context Trust Model — How to source context values (ip, geo, mfa_verified, etc.) safely.
- Access Paths — How policies are evaluated across direct, role, and ABAC paths.
- Decisions — What happens after a policy evaluates.