Skip to content

Trust & security

Security

Authority is built for a world where agents can be compromised. Here is how we protect agent actions, your data and the evidence that proves what happened.

Last updated

Security principles

Authority is security infrastructure, so its own design starts from the same assumption it applies to AI agents: anything that can be influenced by untrusted input can be wrong or hostile.

  • Assume compromise

    Prompts, retrieved content, tool output, memory and the model itself are treated as untrusted.

  • Deterministic floor

    Versioned policy decides. No model, scanner or explanation can override a deny.

  • No standing power

    Agents never hold long-lived credentials; access is brokered just in time.

  • Authority only narrows

    Delegation is an intersection on every dimension — never a union.

  • Evidence by construction

    Every protected action leaves a tamper-evident, independently verifiable record.

  • Privacy-minimized

    Sensitive payloads can stay in your environment; the control plane sees metadata and hashes.

Product security architecture

  • Action-level authorization. Every consequential action is checked against the agent’s task, its delegated authority and your policies before it runs. An approval covers only the exact action that was approved — if anything material changes, it is blocked.
  • One-time access. An allowed action receives short-lived, single-use access that can’t be replayed or reused for anything else.
  • No standing credentials. Downstream credentials are issued only after authorization, with the narrowest scope available. They are never exposed to the agent or written to logs.
  • Egress controls. Outbound destinations are restricted and validated to defend against server-side request forgery and data exfiltration.
  • Fail closed. If Authority can’t verify a high-impact action, the action doesn’t run. Irreversible actions with an unknown outcome are reconciled, never blindly retried.
  • Kill switches. Audited, scoped stops for any tenant, agent, integration, tool or action type.

Data protection

  • Tenant isolation. Tenant context is enforced in request handling, services and data access, including row-level security, tenant-scoped caches, events and keys.
  • Encryption. Data is encrypted in transit with TLS and at rest.
  • Key management. Signing keys live in managed key services (KMS or HSM), are separated by purpose and are rotated without breaking the verification of past records.
  • Data minimization. Raw prompts are not retained by default, and secrets and tokens are never stored in evidence.
  • Deployment choice. Regulated customers can run the enforcement data plane in their own VPC, with residency options for the control plane.

Evidence and auditability

Protected actions produce append-only, tamper-evident records of who asked, which agent and task, the policy version, the decision, any approval, what ran and the outcome. Receipts can be verified independently, policy and configuration changes are versioned and attributable, and evidence can be exported to your SIEM with stable correlation IDs.

Secure development

  • Threat modeling and mandatory review for security-critical code.
  • Static analysis and dependency, container, secret and infrastructure-as-code scanning in CI.
  • Software bills of materials and signed build provenance.
  • An adversarial test suite — covering prompt injection, replay, tampering, privilege escalation and request forgery — runs as a release gate.
  • Independent penetration testing before general availability.

Operations and resilience

We monitor decision latency, deny rates, capability replay attempts, evidence integrity and service health, with runbooks for incidents, key compromise and rollback. Enforcement is promoted per scope and can return to Shadow Mode without a redeploy. Our initial recovery targets for control-plane configuration are a recovery point objective of five minutes or less and a recovery time objective of sixty minutes or less.

Compliance

We are building our security program toward SOC 2 Type II and mapping our controls to ISO 27001, NIST and OWASP guidance for agentic systems. Audit reports will be shared under NDA once available. A data processing agreement is available for customers. For questions, contact 1corporate@clevera.com.

Responsible disclosure

We welcome reports from security researchers. If you believe you have found a vulnerability in Authority or our websites, please email 1corporate@clevera.com with a description, steps to reproduce and any proof of concept. Our contact details are also published in /.well-known/security.txt.

Our commitments

  • We aim to acknowledge reports within three business days.
  • We will keep you informed as we investigate and remediate.
  • We will credit you, with your permission, once a fix is released.

Safe harbor

We will not pursue legal action against good-faith research that follows this policy: avoid privacy violations, data destruction and service degradation; only interact with accounts you own or have permission to test; and give us reasonable time to remediate before any public disclosure.

Out of scope

  • Denial-of-service and volumetric testing.
  • Social engineering, phishing and physical attacks.
  • Vulnerabilities in third-party services we do not control.
  • Accessing, modifying or deleting data that is not yours.

See also our Acceptable Use Policy.