Speedle AI · Patterns

Policy patterns for building and running AI

Speedle’s policy engine applied wherever AI systems touch data, models, tools and other agents: in Build, before a model serves, and in Run, while it serves and acts. These are solution patterns, not shipped integrations with any ML or agent platform.

Each SPDL example below was parsed and evaluated with the Speedle file store against allow and deny cases. Names, paths and attributes are illustrative; your application supplies the attributes when it asks for a decision. The enforcement point must pass every attribute that a condition references.

Build

Before a model serves: data, training and release

01 / Data & training

Which pipelines may train on which data?

Training jobs read datasets, use compute and write checkpoints. The application asks before each dataset read, job start and checkpoint export, passing sensitivity, tenant, consent and region as attributes.

Subjects: Training pipelines as entities; ML engineers and their teams.
Resources and actions: Datasets: read. Training jobs: start. Checkpoints: export.
Enforcement point: The data loader before it opens a dataset, the job scheduler before it allocates compute, and the artifact store before an export.

training.spdlSPDL example

[service.ml-training]
[policy]
# Pipelines read only consented data from their own region
grant role training-pipeline read expr:^/datasets/ if consent == true && data_region == job_region
# Restricted datasets never enter training
deny role training-pipeline read expr:^/datasets/restricted/
grant role ml-engineer start /jobs/training if gpu_hours <= 64
grant role ml-engineer export expr:^/checkpoints/
[rolepolicy]
grant entity pipeline-churn training-pipeline
grant group ml-team ml-engineer

Consent and region checked per dataset, restricted data denied outright, and a GPU-hour limit on job start.

02 / Model release

Who may release a model?

Registering, approving, promoting and rolling back models are separate actions with separate owners. Separation of duties keeps the person who trained a model from approving it.

Subjects: ML engineers, release managers and the service identities of release pipelines.
Resources and actions: Models and endpoints: register, approve, promote, rollback.
Enforcement point: The model registry and the release pipeline, before each change of model or endpoint state.

release.spdlSPDL example

[service.model-registry]
[policy]
grant role ml-engineer register expr:^/models/
grant role release-manager approve, promote, rollback expr:^/models/
# Separation of duties: nobody approves a model they trained
deny role release-manager approve expr:^/models/ if trained_by == request_user
[rolepolicy]
grant group ml-team ml-engineer
grant user dana release-manager

Engineers register but cannot promote; a release manager cannot approve a model whose trained_by is the requesting user.

Run

While AI serves and acts: retrieval, agents, tools and other agents

03 / Inference & RAG

Only what the user may read enters the prompt

Users, apps and tenants call models. For permission-aware RAG (retrieval-augmented generation), the retriever asks Speedle about each document or collection before its content enters the prompt, so the model only sees what the person behind the request may read.

1The retriever finds candidate documents.
2It asks Speedle per document or collection, with the user’s tenant and clearances.
3Only allowed content goes into the prompt.

Subjects: The user behind the request, with their groups; client applications and tenants as entities.
Resources and actions: Collections and documents: retrieve. Models: invoke.
Enforcement point: The retriever before a document enters the prompt, and the API gateway or inference service before it routes a request.

rag.spdlSPDL example

[service.rag]
[policy]
# The retriever asks per document, before its content enters the prompt
grant role tenant-user retrieve expr:^/collections/ if doc_tenant == user_tenant && doc_label in user_clearances
# Documents on legal hold never reach a prompt
deny role tenant-user retrieve expr:^/collections/legal-hold/
# Apps call only the model tiers in their tenant's plan
grant role tenant-app invoke expr:^/models/ if model_tier in plan_tiers
[rolepolicy]
grant group acme-staff tenant-user
grant entity acme-helpdesk tenant-app

A document is retrieved only inside the user’s tenant and at a label the user is cleared for; legal-hold documents are denied, and apps call only the model tiers in their plan.

04 / Agents acting for users

What may an AI agent do on behalf of a user?

The agent has its own identity, and the user’s delegation is proven by a signed delegation token, not by claims in the request. The enforcement point verifies the token, then asks Speedle twice and allows only if both checks pass: the agent within the token’s scope, and the delegating user with their own permissions now. If the user loses a permission after the token was issued, the agent loses it at the next request. A refund above 100 also needs a recorded human approval by someone other than the user.

1Verify the token: signature, issuer, expiry, and that it was issued to this agent.
2Agent scope: ask Speedle with the agent as subject and the token’s scope as attributes.
3Delegator now: ask Speedle with the delegating user, named by the token’s sub claim, as subject.

Subjects: The agent as an entity for the scope check; the delegating user, taken from the verified token, for the second check.
Resources and actions: Tickets: read, update; orders: refund, with the amount as an attribute. All limited to the actions and resources in the token’s scope.
Enforcement point: The agent runtime or the application backend, before the action reaches the business system. It verifies the token and passes only verified claims to Speedle.
Human approval: The enforcement point verifies the signed approval record for the refund and passes its approver as approved_by in the second check. The approver must not be the user.
Self-hosted option: One check, with the token and the delegator evaluated by the custom functions DelegationValid and DelegatorAllowed. Speedle Cloud does not run custom functions.

agents.spdlSPDL example

[service.crm]
[policy]
# Check 1: the agent, only while its verified token covers the request
grant role in-scope read, update expr:^/tickets/
grant role in-scope refund expr:^/orders/
# Check 2: the delegating user (the token's sub), with their roles now
grant role support read, update expr:^/tickets/
grant role support refund expr:^/orders/ if amount <= 100
# Larger refunds: a verified approval by someone other than the user
grant role support refund expr:^/orders/ if approved_by != request_user
[rolepolicy]
# Check 1 in three steps, each role needing the one before:
# the token has not expired,
grant entity triage-agent in-time if request_time < token_expires
# it lists this action,
grant role in-time in-action if request_action in token_actions
# and it lists this resource
grant role in-action in-scope if request_resource in token_resources
# Check 2: the user's own role
grant user alice support

Check 1 gives the agent its role in three steps, so it holds only before the token expires and only for the token’s actions and resources. Check 2 asks about the user alone, so revoking the user’s role denies the agent at the next request. A refund above 100 passes check 2 only with an approver other than the user.

Runnable sample of both patterns on GitHub

05 / Tool calls (MCP)

May this AI agent call this MCP tool, with these arguments?

Every tool call is checked before it runs. The tool is the resource, the call is the action, and the arguments become attributes, so limits such as a refund amount are part of the policy.

Subjects: Agents, each with its own entity identity and role, so privileges stay per agent and per tool.
Resources and actions: Tools: call, with the tool arguments as attributes.
Enforcement point: The MCP client host, or a gateway in front of MCP servers, before the tool executes.

mcp.spdlSPDL example

[service.mcp-gateway]
[policy]
# Tool arguments arrive as attributes and are checked before the tool runs
grant role research-agent call /tools/web-search
grant role billing-agent call /tools/issue-refund if amount <= 100 && customer_verified == true
# Admin tools stay out of reach for research agents
deny role research-agent call expr:^/tools/admin/
[rolepolicy]
grant entity agent-research-1 research-agent
grant entity agent-billing-1 billing-agent

Web search for the research agent, refunds up to 100 for verified customers for the billing agent, and admin tools denied to the research agent.

06 / Agent-to-agent (A2A)

Which agent may call which agent?

Each hop in a delegation chain is checked. The callee may receive only scopes the caller already holds, and the chain has a hop limit, so delegation only narrows permissions.

Subjects: Calling agents, identified as entities.
Resources and actions: Other agents and their skills: call, with the requested scopes, the caller’s scopes and the hop count as attributes.
Enforcement point: The calling agent before it sends a task, or the receiving agent before it accepts one. The application derives the caller’s scopes from the delegation it received.

a2a.spdlSPDL example

[service.a2a]
[policy]
# A callee gets only scopes the caller already holds, within two hops
grant role planner-agent call /agents/researcher if IsSubSet(requested_scopes, caller_scopes) && hops <= 2
grant role researcher-agent call /agents/writer if IsSubSet(requested_scopes, caller_scopes) && hops <= 2
[rolepolicy]
grant entity planner-1 planner-agent
grant entity researcher-1 researcher-agent

IsSubSet rejects any requested scope the caller does not hold, and a third hop is denied.

07 / Zero standing privileges · Self-hosted

Just-in-time tokens support a zero standing privileges pattern

Under the right issuance and control conditions, just-in-time, short-lived, narrowly scoped credentials, combined with Speedle’s policy decisions and application-side enforcement, can support a zero standing privileges pattern. The example checks lifetime, not-before and token status; production also needs a trusted component that verifies the token, binds its claims to the subject, resource, action and task scope, and an atomic consume for single-use credentials.

zsp.spdlSPDL example

[service.zsp]
[policy]
# A just-in-time token: positive lifetime up to 600 s, inside its validity window, unused
# request_time defaults to the ADS clock; attributes passed by the enforcement point take precedence
# 60 s is the explicit clock-skew allowance
grant role agent-runtime invoke /api/orders if expires_at > issued_at && expires_at - issued_at <= 600 && issued_at <= request_time + 60 && not_before <= request_time + 60 && request_time < expires_at && TokenUnused(token_id)
[rolepolicy]
grant entity agent-billing-1 agent-runtime

Full runnable sample on GitHub

Part onePlanned

Target flow for AI risk detection

The approach is being explored and built, not shipped. It adds scrutiny on top of the deterministic policy decision, and a risk signal cannot turn a policy deny into an allow.

Conceptual target flow

Policy first. Risk signals second. Veto intact

Planned

01 / REQUEST
Describe the action
Agent, user, data, action and task context form the request.
Before anything executes
02 / POLICY DECISION
Apply the deterministic boundary
Policy returns the precise decision. Deny stops here; only an allow can continue.
VETO · DENY IS FINAL
03 / AI RISK SIGNALS
Examine wider relationships
The approach being built looks across more dimensions and relationships for additional risk.
PLANNED
04 / FINAL DECISION
Add protection, never access
Risk signals can add scrutiny or protection. The policy outcome and its veto remain intact.
POLICY VETO PRESERVED

A risk signal cannot turn a policy deny into an allow. This diagram shows the approach being built; it does not represent a shipped AI risk-detection capability.

Back to the Speedle AI home page