A2A Policies
Cedar A2A policies.
A2A Policies let you control which agents may invoke which skills on which target agents. They are Cedar policies - a structured, auditable authorization language - compiled from pre-built templates so you do not need to write raw Cedar syntax. Every A2A invocation runs through the Cedar policy engine before reaching the wire; a denied request is refused without ever contacting the remote agent.
Navigate to the policies page from your project's Factory section:
/<org>/<project>/factory/a2a/policiesHow A2A authorization works
When an agent calls an A2A skill (whether via the MCP bridge or a workflow agent.dispatch node), the platform emits a pre-verb event on the Layer-6 hook bus before the outbound HTTP call. The Cedar policy engine evaluates the request against all enabled policies for the org and project. If any forbid policy matches, or if no permit policy matches, the invocation is denied and an AuthorizationError is returned to the caller.
The Cedar principal for an A2A call is an A2AAgent entity constructed from the agent_cards row: it carries the agent's id, agentUrl, orgId, skill capability set, and trust level. The Cedar action is one of:
| Cedar action | When it fires |
|---|---|
a2a_invoke | Before calling a skill (the common case) |
a2a_discover | When a session enumerates an agent's skills |
a2a_cancel | When a task cancellation request is issued |
Policy templates
Rather than writing raw Cedar, you create policies from templates. Each template declares typed inputs and compiles to valid Cedar text. The available templates cover the most common access control patterns:
Creating a policy
Go to Factory → A2A → Policies in your project.
Click Create policy.
Select a template from the picker. Each template shows its effect (permit or forbid) and the Cedar action it targets.
Fill in the template inputs. Required fields are validated before compilation.
Give the policy a name - used only for display; the Cedar text is the authoritative record.
Click Create. The platform compiles the template to Cedar text, validates it against the Cedar schema, and stores it in the a2a_policies table.
API reference
The policies API is available at /api/factory/a2a/policies. Authentication is session-cookie only - CLI bearer tokens (rsk_*) are not supported on this route.
List policies
GET /api/factory/a2a/policies?projectId=<projectId>Returns all enabled and disabled policies for the given project within your org.
Response:
{
"policies": [
{
"id": "a2apol_m2x4r_abc123",
"orgId": "org_...",
"projectId": "proj_...",
"name": "Allow code-reviewer to call deploy-agent",
"cedarText": "// a2a-tpl-allow-skill\npermit (...)",
"enabled": true,
"templateId": "a2a-tpl-allow-skill",
"createdAt": "2026-06-01T12:00:00.000Z",
"updatedAt": "2026-06-01T12:00:00.000Z"
}
]
}Create policy from template
POST /api/factory/a2a/policies
Content-Type: application/json
{
"projectId": "proj_...",
"templateId": "a2a-tpl-allow-skill",
"inputs": {
"callerAgentId": "agent-card-id-1",
"targetAgentId": "agent-card-id-2",
"skillId": "review"
},
"name": "Allow code-reviewer",
"enabled": true
}Returns 201 with the created policy on success. Returns 400 when templateId is unknown, inputs fail validation, or the compiled Cedar text fails schema validation.
Update or delete a policy
PATCH /api/factory/a2a/policies/<id>
DELETE /api/factory/a2a/policies/<id>Use the PATCH endpoint to toggle enabled, rename the policy, or change its Cedar text. Use DELETE to remove a policy permanently.
Policy scoping
Policies are currently scoped to a project by encoding the projectId in the policy name as a prefix: [proj:<projectId>] <user-name>. The GET route filters by this prefix. This is a transitional convention - a first-class project_id column on a2a_policies is planned and will move filtering to a SQL WHERE clause.
Enabling and disabling policies
Set enabled: false on a policy to suspend it without deleting it. Disabled policies are excluded from Cedar evaluation. This is useful during incident response when you want to quickly revoke a permission without losing the policy definition.
Cedar is an explicit-permit model: if no permit policy matches a request, the default decision is deny. Disabling your only permit policy for an agent pair will immediately block all invocations between those agents.
Admin-level raw Cedar authoring
Operators with admin access can author raw Cedar policies at /admin/a2a/policies. This surface accepts arbitrary Cedar text and is not template-constrained. Use it for complex scenarios that the template library does not cover. Changes made here are visible across all projects in the org.
Related pages
- A2A Registry - register and manage agents
- A2A Agent Detail - per-agent trust level and policy summary
- A2A MCP Bridge - where the Cedar
pre-verbhook fires - Cedar Policies - platform-wide Cedar policy engine