The Three-Tier Control Architecture

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

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:

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

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