Organization card templates

Organization card templates require an Enterprise plan. Contact sales to enable this feature.

Org card templates let you define base policies that every agent in your organization inherits across two separate cards:

Alignment card template — org-level values, behavioral commitments, and audit requirements. Agents can add but cannot remove what the org defines.
Protection card template — org-level protected_surface (assets, forbidden operations, escalation requirements), thresholds, and screen surfaces. The protected_surface is the org’s enforced policy, not the agent’s self-declaration. Safe House L2 enforces it independent of what the agent declares in its alignment card. An empty or naive agent still gets the org floor applied.

The alignment card template section below covers the alignment side. The Protection card template and protected_surface section below covers the protection side.

How it works

The org card template establishes a floor for alignment policy. Every agent’s canonical card is computed by composing the org template with the agent’s individual card:

Org Template (base) + Agent Card (additive) = Canonical Card (used for verification)

The org template defines the non-negotiable alignment requirements. Individual agent cards add agent-specific values, actions, and triggers on top. This is similar to how an organization might have company-wide policies that every employee follows, while individual teams add their own domain-specific guidelines.

Setting up

Visual editor vs JSON editor

The visual editor provides form-based inputs for each card block with inline validation. Use it for initial setup and when making incremental changes. The JSON editor shows the raw template JSON. Use it for bulk edits, copying from a file, or when you need precise control over the template structure.

Both editors validate on save. The JSON editor is faster for teams that maintain their org template in version control and paste updates from a file.

Composition rules

When the org template is active, each field in the canonical card is computed according to these rules:

Card Field	Composition Rule	Example
`values.declared`	Union of org + agent values	Org: `[honesty, transparency]` + Agent: `[editorial_independence]` = `[honesty, transparency, editorial_independence]`
`values.definitions`	Merged. Agent definitions cannot override org definitions	Org defines `honesty`; agent can define `editorial_independence` but not redefine `honesty`
`values.hierarchy`	Org hierarchy takes precedence if defined	Org sets `lexicographic`; agent cannot change to `weighted`
`values.conflicts_with`	Union of org + agent conflicts	Org: `[deception]` + Agent: `[upsell_pressure]` = `[deception, upsell_pressure]`
`autonomy_envelope.bounded_actions`	Agent-specific (org does not restrict)	Agent defines its own bounded actions
`autonomy_envelope.forbidden_actions`	Union of org + agent forbidden actions	Org: `[exfiltrate_data]` + Agent: `[delete_records]` = `[exfiltrate_data, delete_records]`
`autonomy_envelope.escalation_triggers`	Union of org + agent triggers	Org triggers always apply; agent adds more
`audit_commitment.retention_days`	Maximum of org and agent value	Org: 180 days, Agent: 365 days = 365 days
`audit_commitment.queryable`	Org `true` cannot be overridden to `false`	If org requires queryable, all agents are queryable
`audit_commitment.tamper_evidence`	Strongest mechanism wins (`merkle` > `signed` > `append_only`)	Org: `signed`, Agent: `merkle` = `merkle`

Composition is always additive from the agent’s perspective. Agents can strengthen alignment requirements but never weaken them below the org floor.

Protection card template and `protected_surface`

The protection card template is the org’s enforced protection policy. Where the alignment card template defines what agents declare they will do, the protection card template defines what Safe House enforces regardless of agent behavior or instructions. The protected_surface field is the core of the protection card template:

# Example org protection card template
protected_surface:
  assets:
    # What is precious — sealed records, sensitive fields, critical resources.
    - kind: table
      selector: customer_pii
      label: "Customer PII"
      reason: "Regulated data — any bulk operation requires escalation"
    - kind: field
      selector: replica_dsn
      label: "Replica connection string"
      reason: "Credential — never expose in agent output"
  forbidden_operations:
    # Categorically forbidden — Safe House blocks these regardless of agent instruction.
    - pattern: "TRUNCATE"
      severity: critical
      reason: "Irreversible data loss"
    - pattern: "exfiltrate:pii"
      severity: critical
      reason: "PII exfiltration forbidden"
  escalation_required:
    # Actions that need elevated authority before proceeding.
    - pattern: "bulk DELETE"
      applies_to: ["table:customer_pii"]
      reason: "Bulk deletions on regulated data require a co-sign"

Composition rules for protected_surface:

Array	Rule	Agent can…
`assets`	Strengthen-only union across platform → org → team → agent	Add assets; never remove or narrow a higher-scope entry
`forbidden_operations`	Strengthen-only union; on pattern collision severity takes the max	Add operations; never remove or weaken a higher-scope entry
`escalation_required`	Strengthen-only union	Add requirements; never remove a higher-scope entry

Coverage is workload-independent: an empty or naive agent still gets the full org protected_surface applied. The agent’s alignment card autonomy.forbidden_actions is its behavioral commitment; the protection card’s protected_surface.forbidden_operations is the org’s hard policy enforced by Safe House. The two are complementary, not redundant.

Agent exemptions

In rare cases, an agent may need to operate without the org template. For example, a testing agent that intentionally exercises boundary conditions, or an agent operating under a different regulatory framework.

Exemption flow

Exemptions require a double-confirm process:

Requirements

Role: Owner or admin role required
Audit trail: Every exemption (grant and revoke) is logged with actor, reason, and timestamp
Visibility: Exempted agents are flagged in the dashboard and API responses

Revoking an exemption

To restore org template inheritance, navigate to the agent’s page and click Revoke Exemption in the Alignment Card section. The agent’s canonical card immediately recomposes with the org template.

API

The legacy whole-card org_card_exempt flag was replaced in the 2026-04-15 unified-cards consolidation by section-specific exemptions that target one field of the org card at a time, with audit metadata. Manage them via:

# List active exemptions on an agent
curl https://api.mnemom.ai/v1/agents/{agent_id}/exemptions \
  -H "Authorization: Bearer YOUR_TOKEN"

# Grant a new exemption (required: exempt_section, reason)
# exempt_section is closed-enum:
#   "autonomy.forbidden_actions" | "enforcement.forbidden_tools" | "autonomy.max_autonomous_value"
curl -X POST https://api.mnemom.ai/v1/agents/{agent_id}/exemptions \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "exempt_section": "autonomy.forbidden_actions",
    "exempt_patterns": ["no_external_api_calls"],
    "reason": "Adversarial alignment testing agent — external probes required",
    "expires_at": "2026-08-15T00:00:00Z"
  }'

# Revoke (use the exemption_id returned from the list/POST)
curl -X DELETE https://api.mnemom.ai/v1/agents/{agent_id}/exemptions/{exemption_id} \
  -H "Authorization: Bearer YOUR_TOKEN"

Exemptions are time-bounded (default 90-day expiry), audit-logged, and section-specific. See the Unified Cards overview for the canonical exemption model and the Card Composition page for how exemptions interact with the platform → org → agent cascade.

Relationship to conscience values

Org card templates and custom conscience values are complementary features that operate at different layers:

Feature	What It Controls	When It Applies
Org card template	The alignment card (values, boundaries, audit commitment)	At card composition time and during AAP verification
Custom conscience values	The conscience prompt used by AIP for per-turn integrity checks	At every AIP integrity checkpoint

Think of it this way:

The org card template defines what your agents declare they will do (their alignment posture)
Custom conscience values define what AIP looks for when evaluating whether agents are actually doing it (the evaluation criteria)

Both work together to create a comprehensive organizational alignment policy. The card template sets the declared boundaries; conscience values ensure those boundaries are evaluated during per-turn analysis (and gated same-turn in enforce).

You can use one without the other. An org that only sets conscience values gets per-turn evaluation policy without modifying agent cards. An org that only sets a card template gets consistent declared alignment without customizing the evaluation criteria.

Overview

Concepts

Gateway

Pricing

Migrations

Policy

Specifications

Changelog

Organization Card Templates

Organization card templates

How it works

Setting up

Visual editor vs JSON editor

Composition rules

Protection card template and `protected_surface`

Agent exemptions

Exemption flow

Requirements

Revoking an exemption

API

Relationship to conscience values

See also

​Organization card templates

​How it works

​Setting up

​Visual editor vs JSON editor

​Composition rules

​Protection card template and protected_surface

​Agent exemptions

​Exemption flow

​Requirements

​Revoking an exemption

​API

​Relationship to conscience values

​See also

Organization card templates

How it works

Setting up

Visual editor vs JSON editor

Composition rules

Protection card template and `protected_surface`

Agent exemptions

Exemption flow

Requirements

Revoking an exemption

API

Relationship to conscience values

See also