Features

Continuous Verification

AVON does not rely on a single authentication event. Once a tunnel is established:

• A cryptographic heartbeat is sent every 10 seconds (configurable)
• Session tokens rotate every 30 seconds
• Policy is re-evaluated on every heartbeat — if a device falls out of compliance or policy changes, access is revoked in real time
• Dead sessions are automatically cleaned up

Attribute-Based Access Control

Policies are evaluated based on multiple contextual attributes:

policy:
  name: engineering-production
  rules:
    - name: allow-ssh-production
      action: allow
      subjects:
        groups: [engineering]
        attributes:
          role: senior-engineer
      resources:
        networks: [10.100.0.0/16]
        ports: [22]
        protocols: [tcp]
      conditions:
        time:
          days: [monday, tuesday, wednesday, thursday, friday]
          hours: {start: "08:00", end: "20:00", timezone: "America/New_York"}
        device:
          os: [macOS, Linux]
          posture: compliant

    - name: deny-all
      action: deny
      subjects: {}
      resources: {}

Policy evaluation order:

1. Explicit DENY rules (highest priority)
2. Explicit ALLOW rules
3. Default DENY (implicit)

Cross-Platform Agent

The agent is a single Rust binary with minimal footprint:

Supported platforms:

Key Management & Certificate Authority

AVON operates its own post-quantum certificate authority:

Root CA Key (Dilithium)
├── Storage: HSM (production) or encrypted file (dev)
├── Validity: 10 years
└── Signs → Intermediate CA

Intermediate CA Key (Dilithium)
├── Validity: 2 years, rotated annually
└── Signs → Agent Certificates

Agent Certificates (Dilithium)
├── Generated on-device during enrollment
├── Private key never leaves the device
├── Validity: 1 year, auto-renewed
└── Storage: OS-native secure storage
    ├── Linux: System keyring
    ├── macOS: Keychain Services
    ├── Windows: DPAPI + Credential Manager
    └── TPM 2.0 (when available)

Session Keys (AES-256)
├── Derived from Kyber key exchange
├── Ephemeral, per-session
└── Rotated every 24 hours

Monitoring & Observability

Every AVON service exposes:

• Prometheus metrics on port 9090
• Health checks on port 8080 (/health and /ready)
• Structured JSON logging via tracing-subscriber

Key metrics include active connections, authentication latency, heartbeat rates, policy decision distributions, and error rates. A Grafana dashboard is included for real-time visibility.

Compliance Readiness

AVON’s architecture supports compliance with:

• SOC 2 Type II
• HIPAA
• PCI DSS
• GDPR
• FedRAMP
• NIST 800-53

All security events are logged with actor, action, resource, outcome, and context for full audit trails.

How It Works

Enrollment

When a new device is onboarded to AVON:

1. An administrator generates an enrollment token via the Admin API or UI
2. The agent generates a Dilithium-5 key pair locally — the private key never leaves the device
3. The agent sends its public key and enrollment token to the CA service
4. The CA validates the token, issues a post-quantum certificate, and returns it to the agent
5. The agent stores its credentials in OS-native secure storage

sudo avon-agent enroll 
  --gateway gateway.avon.example.com:4600 
  --token "ENROLLMENT_TOKEN_HERE" 
  --name "alice-laptop"

Tunnel Establishment

Once enrolled, the agent establishes a secure tunnel:

1. Key Exchange — Agent and Gateway perform a Kyber-1024 key encapsulation to derive a shared secret
2. Authentication — Agent presents its Dilithium certificate and signs a challenge to prove identity
3. Policy Check — The Policy Engine evaluates whether this device should be granted access based on identity, groups, device posture, time, and location
4. Session Creation — Auth Service issues a session token bound to the certificate fingerprint
5. Tunnel Active — Traffic flows through an AES-256-GCM encrypted UDP tunnel via the TUN interface (avon0)

Continuous Verification (Pulse)

Every 10 seconds while a session is active:

1. Agent sends an encrypted heartbeat with a fresh Dilithium signature
2. Pulse Service validates the session and signature
3. Policy Engine re-evaluates access — if policy has changed or the device is no longer compliant, the session is terminated
4. Session token is rotated and a new token is sent back to the agent

If a heartbeat is missed, the session is marked for cleanup. There is no silent persistence — access requires continuous proof.