agentrc separates what an agent requests from what a platform enforces. An author writes a Dockerfile-shaped Agentfile; the build emits namespaced ai.agentrc.* OCI labels; the platform reads those labels — never the Agentfile source — and grants, narrows, or rejects each request, then enforces the result with Cedar, platform-side. The Agentfile expresses intent; the platform holds authority.

A POLICY line or a presence label is a request, not a permission. Absence of a grant is a denial. The enforcement engine is Cedar, and it lives on the platform, not in the artifact.

Every security-relevant boundary is declared as a label the compiler emits from authored intent, and enforced by the platform's Cedar engine. Authors write the short forms; the compiler prepends ai.agentrc..

The platform sees a uniform, machine-readable manifest of everything the agent asks for — tools, network, devices, MCP servers, and sub-agents — and vets it before the agent runs.

Secrets are deferred in this draft — no SECRET/CRED keyword and no ai.agentrc.secret.* schema; credential resolution is platform-defined and out of scope for now.

When a POLICY value is a URL the agent will call out to — agent.hooks.* or agent.interrupt_endpoint — the compiler auto-derives a corresponding network egress label and attributes it, so a webhook can never open a silent network hole:

ai.agentrc.network.dns.hooks.internal=443
ai.agentrc.network.dns.hooks.internal.source=auto:agent.hooks.pre

Auto-derivation is an ergonomic convenience, not an implicit grant. The platform must still grant the derived egress; an un-granted one is denied.

• Requests, not enforcement. A POLICY line or a presence label asks the platform for something. The platform decides.
• Deny-by-default. Absence of a grant is a denial. An unrecognised request, an un-granted auto-derived egress, or an action with no matching grant is denied.
• forbid overrides permit, order-independently. An organization forbid (e.g., "no agent may reach the public internet") defeats any agent request, regardless of evaluation order.
• Tightening-only across FROM. When an agent inherits from another agent, its effective authorization is the intersection of ceilings — a child cannot exceed its parent, and a parent forbid is un-loosenable.
• Fail closed. A platform that cannot understand, evaluate, or enforce a required boundary MUST refuse to run the agent rather than run it under-protected.
• No policy language in the Agentfile. Authors write only typed POLICY requests. Cedar is platform-side only — there is no permit / forbid in an Agentfile, and no second, author-facing policy language to learn.

Cedar is the platform's enforcement engine and compilation target, not an author surface. For each granted request the platform derives Cedar entities and evaluates them. The principal is the agent identity (ai.agentrc.identity.name); the action and resource come from the request namespace:

The agent's POLICY requests are the floor of intent; the organization's own Cedar policies (authored out-of-band by the security team) are the ceiling of authority. The platform compiles both into one Cedar PolicySet and evaluates the grant. The Enforcement (Cedar) profile is the normative home of this mapping and the conformance requirements.