Skip to main content
Back to Blog
Security

Building a 3-Tier Progressive Compliance Agent

Thomas Scola
••3 min read

Building a 3-Tier Progressive Compliance Agent

One of the biggest hurdles to enterprise agent adoption is the "Compliance Wall." Security teams often block agentic workflows because they lack the granular controls found in traditional software.

To solve this, we advocate for a 3-Tier Progressive Compliance Model. This architectural pattern allows you to start fast and layer on governance as your agent's autonomy and data access increase. This model is a core pillar of the Open Standard Agents (OSSA) design philosophy.

Tier 1: Core (The Prototyping Sandbox)

At Tier 1, the focus is on Discovery and Execution. This is where most developers start.

Key Characteristics:

  • Loose Coupling: The agent has access to generic tools.
  • Minimal Metadata: Focus is on the system prompt and basic capability matching.
  • Logging: Basic application logs (stdout).

Implementation Check:

If you are building a Tier 1 agent, your focus should be on Capability Mapping. Ensure your agent manifest clearly defines what the agent can do, even if you haven't restricted how it does it yet.

Tier 2: Governed (The Enterprise Standard)

As soon as an agent touches PII, financial data, or production infrastructure, it must move to Tier 2. This is the "sweet spot" for most production systems.

Key Characteristics:

  • Identity & Auth: Every agent must have a unique identifier and an assigned service account.
  • Policy Enforcement: Rules are moved out of the prompt and into a declarative policy engine (like Cedar or OPA).
  • Audit Trails: Every tool call and reasoning step is logged to a secure, immutable store.

Building for Tier 2:

When contributing to the OSSA specification, we defined the Policy kind specifically for this tier. A Tier 2 agent shouldn't just "be told" not to delete data; it should be physically prevented from doing so by the runtime substrate.

# Example Tier 2 Governance
compliance:
  tier: governed
  policyRef: "policy/data-retention-v1"
  auditLevel: detailed

Tier 3: Advanced (The Regulated Frontier)

For agents operating in HIPAA, SOC2, or FedRAMP environments, Tier 3 is mandatory.

Key Characteristics:

  • Formal Verification: The agent's manifest is validated against a strict JSON Schema before every deployment.
  • mTLS Everywhere: All inter-agent communication happens over an encrypted mesh with verified certificates.
  • Deterministic Guardrails: Output is scanned for PII or toxic content before it ever reaches a user or a downstream tool.

Why Progressive Compliance Matters

The goal isn't to force every agent to meet SOC2 requirements on day one. It's to ensure that the Architecture you choose for Tier 1 can naturally evolve into Tier 3.

By following a standardized manifest format like OSSA, you ensure that your "toy" agent built in a weekend isn't a dead-end. You can layer on the security, observability, and policy hooks as the business value—and risk—grows.

Is your agent architecture ready to scale? Evaluate your current stack against these three tiers. If you can't easily add an audit trail or a policy engine, you aren't building for the enterprise.

For technical deep dives into the governance schemas, explore the OSSA Security Track.

compliancegovernancesecurityAgentOps
Back to All Posts