# Three-Tier Architecture

> How ACS splits responsibility across Platform, Enforcement, and Enterprise layers

- **Category**: guardrails-acs

- **Canonical URL**: https://designpattern.fyi/guardrails-acs/three-tier-architecture/

---

## Description
How ACS splits responsibility across Platform, Enforcement, and Enterprise layers








## Additional Notes

# The Three-Tier Control Architecture

ACS deliberately splits responsibility so that no single layer has to solve the whole problem.

{{< mermaid >}}
flowchart TB
    subgraph T1["Tier 1 — Platform layer (one-time)"]
        A[Agent framework exposes<br/>standardized hooks]
    end
    subgraph T2["Tier 2 — Open-source enforcement layer"]
        B[Framework-agnostic SDK<br/>reads declarative policy<br/>and enforces via hooks]
    end
    subgraph T3["Enterprise customization layer"]
        C[Custom classifiers:<br/>PII/PHI detectors, cost control,<br/>industry-specific rules]
    end
    A -->|hook events| B
    C -->|plugs into| B
    B -->|verdict: allow / deny / modify| A
{{< /mermaid >}}

---

## Tier 1 — Platform Layer

### One-Time Integration
The agent framework or platform does the integration once: expose the hooks.

### Platform Responsibilities
- **Hook exposure** — implement AOS hook methods at decision points
- **Event emission** — fire hook events with required context
- **Verdict handling** — implement allow/deny/modify logic
- **Trace emission** — emit OpenTelemetry spans for each hook

### What the Platform Doesn't Need
- **Policy understanding** — the platform doesn't need to understand policy
- **Security logic** — enforcement logic lives in Tier 2
- **Enterprise specifics** — organizational rules live in Tier 3

### Platform Examples
- **LangChain** — agent framework with AOS hook integration
- **CrewAI** — multi-agent framework with hook support
- **Internal runtimes** — custom agent platforms implementing AOS hooks
- **Model providers** — LLM platforms with built-in hook support

### Why This Separation Matters
- **Framework portability** — switch frameworks without rewriting security logic
- **Vendor neutrality** — use any agent platform with the same enforcement layer
- **Reduced integration burden** — one-time integration rather than per-policy

---

## Tier 2 — Enforcement Layer

### Framework-Agnostic SDK
An open-source, framework-agnostic SDK reads declarative policy and enforces it through hooks.

### Enforcement Layer Responsibilities
- **Policy evaluation** — read and interpret declarative policy
- **Hook processing** — receive and evaluate hook events
- **Verdict generation** — return allow/deny/modify with reasoning
- **Policy management** — policy versioning, testing, deployment

### Built-in Policy Categories
The enforcement layer includes common policy categories:

- **Input validation** — reject injection patterns, out-of-scope topics
- **Tool-call authorization** — evaluate tool requests against policy
- **Output filtering** — redact sensitive information, block unsafe responses
- **Adversarial-input detection** — identify and block jailbreak attempts
- **Cost control** — enforce rate limits, resource quotas
- **Destructive-action review** — require approval for high-impact actions

### Policy Language
The enforcement layer uses a declarative policy language:

```
hook: message (role=user)
policy: reject-known-injection-patterns, reject-out-of-scope-topics
verdict-on-match: deny
verdict-on-clean: allow
```

### Why This Separation Matters
- **Standardization** — same policy language across frameworks
- **Portability** — switch agent platforms without rewriting policies
- **Collaboration** — security teams can review and approve policies
- **Testing** — policies can be tested independently of agent implementation

---

## Tier 3 — Enterprise Customization Layer

### Organization-Specific Classifiers
Your organization's own detectors plug into Tier 2 without touching the platform.

### Enterprise Layer Responsibilities
- **Custom classifiers** — organization-specific detection logic
- **Industry rules** — sector-specific regulations and requirements
- **Data sensitivity models** — organizational data classification
- **Compliance mappings** — regulatory requirement to control mapping

### Enterprise Classifier Examples
Different industries bring different classifiers:

| Industry | Example Classifiers |
|---|---|
| **Financial Services** | Data sensitivity models, transaction monitoring, fraud detection |
| **Healthcare** | PHI detection, HIPAA compliance, patient data privacy |
| **Government** | Classification handling, access control, audit requirements |
| **Technology** | IP protection, code security, API abuse prevention |

### Integration Pattern
Enterprise classifiers plug into the enforcement layer:

- **As policy extensions** — additional rules evaluated by Tier 2
- **As external services** — classification APIs called during evaluation
- **As custom modules** — pluggable components loaded by the enforcement SDK

### Why This Separation Matters
- **Flexibility** — organizations can encode specific requirements
- **Privacy** — sensitive rules don't need to be shared with platform vendors
- **Regulatory compliance** — industry-specific requirements can be implemented
- **Investment protection** — existing security tooling can be integrated

---

## How the Tiers Work Together

### Event Flow
1. **Tier 1** — Agent framework fires a hook event
2. **Tier 2** — Enforcement SDK receives the event, evaluates policy
3. **Tier 3** — Enterprise classifiers provide additional context
4. **Tier 2** — Enforcement SDK generates verdict (allow/deny/modify)
5. **Tier 1** — Agent framework handles the verdict

### Policy Flow
1. **Tier 3** — Enterprise defines custom classifiers and rules
2. **Tier 2** — Enforcement SDK loads and integrates enterprise policies
3. **Tier 2** — Policy evaluation combines built-in and enterprise rules
4. **Tier 1** — Agent framework is unaware of policy specifics

### Benefits of This Architecture

| Benefit | Description |
|---|---|
| **Portability** | Switch agent frameworks without rewriting security logic |
| **Standardization** | Common policy language across platforms |
| **Collaboration** | Security teams can review policies without understanding frameworks |
| **Extensibility** | Organizations can add custom rules without touching platforms |
| **Testing** | Each layer can be tested independently |
| **Maintenance** | Clear ownership boundaries reduce coordination overhead |

---

## Implementation Considerations

### Tier 1 Implementation
- **One-time cost** — implement hooks once per framework
- **Standard interface** — use AOS hook specifications
- **Minimal policy logic** — focus on event emission and verdict handling
- **Framework support** — check if your framework already has AOS integration

### Tier 2 Implementation
- **Choose an SDK** — select or build an enforcement SDK
- **Policy development** — develop declarative policies for your use cases
- **Testing** — test policies in isolation before deployment
- **Monitoring** — track policy evaluation metrics and false positives/negatives

### Tier 3 Implementation
- **Identify requirements** — map organizational and regulatory requirements
- **Develop classifiers** — build or integrate detection logic
- **Test integration** — verify classifiers work with enforcement SDK
- **Maintain updates** — keep classifiers current with changing requirements

---

## Key Takeaways

1. **Tier 1 (Platform)** — one-time hook integration, no policy logic required
2. **Tier 2 (Enforcement)** — framework-agnostic SDK with declarative policy language
3. **Tier 3 (Enterprise)** — custom classifiers for organizational requirements
4. **Clear separation** — each layer has distinct responsibilities and boundaries
5. **Portability** — switch frameworks without rewriting security logic

---

## Next Steps

- **OWASP Risk Mapping** — see how the three-tier architecture addresses specific risks
- **Implementation Guide** — follow the step-by-step process to implement each tier