sema-policies

Reusable least-privilege, content-safety, human-review, output, and workflow-evidence policies.

These policies are deterministic runtime controls, not legal or regulatory certifications. Content profiles cover Sema's documented detectors; they do not classify arbitrary sensitive information or prove that a statement is true.

Install

sema pkg add sema-policies

Version 0.2.0 requires Sema 1.34.0 or newer.

Safe coding agent

(import "sema-policies")

(define project-policy
  (policies/safe-code-agent
    {:models ["openai/gpt-5" "ollama/*"]
     :read ["src/**" "tests/**" "Cargo.toml"]
     :write ["src/**" "tests/**"]
     :commands ["cargo test" "git diff"]
     :domains ["docs.rs"]}))

(defworkflow inspect-and-test "Inspect a repository under a strict policy."
  {:policy project-policy}
  (phase "Inspect")
  (step "Inspect the project and run its tests." {:tools [read-file write-file run-command]})
  {:status :success})

Commands are exact strings. Network access defaults to GET and HTTPS is still subject to the core domain selector. Tool definitions must declare semantic policy subjects; an undeclared tool is denied by this profile.

:network-methods is valid only with a non-empty :domains list. An explicitly empty method list is rejected instead of being interpreted as unrestricted.

Policy lists compose as an intersection: every layer must allow an operation, and the strictest content action wins.

Human review

policies/human-reviewed-run makes a successful run require an applied, signature-validated approval gate:

(import "sema-policies")

(defworkflow publish-report "Review before publication."
  {:policy policies/human-reviewed-run}

  (phase "Draft")
  (define report (checkpoint :report (build-report)))

  (phase "Review")
  (approval :editor-signoff
    {:reason "Publish a public report"
     :subject {:kind :external-action
               :target "public-site"
               :report-digest (hash/sha256 report)}
     :preview "Publish the reviewed report"})

  (phase "Publish")
  (publish-report report)
  {:status :success})

Place the explicit gate immediately before the protected action. The profile requires that some approval.applied event occurred before success; it does not automatically attach a gate to a matching tool call or prove that a particular gate authorized a particular later action.

policies/change-controlled also requires :owner, :change-id, and :environment workflow metadata.

API

Constructors and rule builders

Function	Description
(policies/model-allowlist identities opts?)	Allow exact provider/model identities or provider/*
(policies/tool-allowlist rules opts?)	Allow named tools with path, domain, or exact-command constraints
(policies/subject-allowlist rules opts?)	Allow only matching semantic tool subjects; :deny rules take precedence
(policies/file-read-rule paths)	Build a :file-read subject rule
(policies/file-write-rule paths)	Build a :file-write subject rule
(policies/file-delete-rule paths)	Build a :file-delete subject rule
(policies/network-rule domains opts?)	Build a network rule; :methods restricts HTTP methods
(policies/command-rule commands)	Build an exact-command rule
(policies/external-action-rule actions)	Build a rule for exact declared action names
(policies/input-controls detectors opts?)	Configure deterministic input detectors and actions
(policies/evidence-requirements requirements)	Require workflow metadata and/or event kinds
(policies/read-only-repository paths)	Allow declared file reads under selected paths and deny other subject kinds
(policies/output-contract contract)	Enforce an arbitrary core output policy map

Use one combined policies/subject-allowlist when several subject kinds must be allowed. Two separate default-deny subject policies intersect and can deny each other's otherwise valid operations.

(policies/subject-allowlist
  [(policies/file-read-rule ["src/**" "Cargo.toml"])
   (policies/file-write-rule {:allow ["src/**"]
                              :deny ["src/generated/**"]})
   (policies/network-rule ["api.example.com"] {:methods ["GET"]})
   (policies/command-rule ["cargo test"])
   (policies/external-action-rule ["ticket-read"])])

Path and domain arguments accept either a non-empty shorthand sequence or the core selector map with :allow and :deny. Domain selectors may also specify :schemes and :ports.

Configurable input controls

(policies/input-controls
  [:secret :payment-card :email]
  {:actions {:secret :block
             :payment-card :block
             :email :redact}})

Supported detector families are :secret, :payment-card, :email, :phone, and :ipv4. Actions are :audit, :redact, or :block; a detector without an explicit action blocks.

Evidence requirements

(policies/evidence-requirements
  {:metadata [:owner :intended-purpose]
   :events [:checkpoint :approval.applied]})

Metadata values must be present and non-empty. Completion requirements match event kinds, not event fields. They cannot yet require a particular checkpoint key, tool name, command, or approval key.

Output controls

policies/output-contract exposes the core :output map:

(policies/output-contract
  {:schema {:answer {:type :string}
            :sources {:type :list}}
   :require [:answer :sources]
   :max-length 8000
   :forbid [{:id :no-placeholder :contains "TODO"}]})

Supported field types are :string, :number, :boolean, and :list. Structural checks run on the terminal LLM response. Detector and forbidden pattern checks also guard agent rounds and buffered streams. They do not validate the value returned directly by the workflow body.

The fixed output profiles are:

Policy	Behavior
policies/reviewable-output	Require non-empty answer, sources, and limitations; allow optional numeric confidence
policies/certainty-audit	Journal a small, independently authored set of absolute-certainty and unnamed-consensus patterns without blocking
policies/no-placeholder-output	Block objective unfinished-template markers

certainty-audit is intentionally advisory. Quoted text and valid contractual language can match its patterns. It is not a port of HeartFlow and does not implement semantic truth, fallacy, manipulation, or factuality classification.

Deny-only profiles

These policies use :subjects {:default :allow ...} so they can tighten a separate allowlist without denying unrelated subject kinds:

Policy	Denies through model-invoked/direct deftool dispatch
policies/no-file-write-tools	File writes and deletes
policies/no-network-tools	Network requests
policies/no-command-tools	Commands
policies/no-external-action-tools	External actions

The names include tools because semantic policy subjects govern declared tool dispatch. Ordinary Sema filesystem, HTTP, shell, and MCP calls remain governed by workflow :permissions and the outer sandbox.

Fixed baselines and domain profiles

Policy	Behavior
policies/no-tools	Deny every model-requested tool call
policies/no-sensitive-data-to-models	Block detected secrets/cards and redact supported personal-data patterns before provider dispatch
policies/public-content	Block every supported sensitive-content detector on LLM input and output
(policies/safe-code-agent options)	Combine model, semantic subject, and input controls for coding agents
(policies/customer-support-safe options)	Draft-only support profile that permits exact read-only external-action names and requires structured drafts
policies/human-reviewed-run	Require an applied approval before workflow success
policies/change-controlled	Require change metadata and an applied approval
policies/public-sector-rag	Require ownership/source metadata, structured cited output, content controls, and a checkpoint
policies/ai-act-docs-lite	Require basic ownership/risk/purpose metadata, structured decision records, and a checkpoint
policies/ai-act-human-oversight	Require fuller purpose/affected-person/oversight metadata, structured limitations, a checkpoint, and approval
policies/employment-assist	Disable model tools, require neutral evidence/limitations/review output and metadata, and require approval

customer-support-safe is deliberately draft-only. Its :read-actions must match the :external-action values declared by the permitted read tools. Any additional subject declared by those tools must also be allowed by a different, carefully designed profile; policy composition cannot loosen this profile.

employment-assist does not provide protected-attribute or health detectors. It blocks model tools and enforces a review-shaped output and explicit approval; it is not a candidate-ranking or employment-decision system.

The AI documentation profiles generate runtime evidence requirements. They do not establish EU AI Act compliance.

Evidence export

sema workflow export <run-id>

The command writes a JSON ledger, Markdown summary, and SHA-256 manifest under the run directory by default. Approval request and decision summaries are read through Sema's digest and Ed25519 signature validation. The authoritative approval sidecars are included in the integrity manifest.

Testing

sema pkg add sema-test
sema tests.sema

License

MIT