Security & Compliance

Asyrx is AI Agent Action Security: it evaluates proposed consequential agent actions before execution and returns Action Risk, Blast Radius, risk level, risk factors, reason codes, behavioural context, policy context, confidence, recommended controls, and human-review recommendations.

Asyrx is a decision-support layer. It does not authorize, approve, deny, block or execute customer actions, and it does not replace identity, authorization or policy-enforcement systems. The customer retains control of execution.

Asyrx is built on modern cloud and edge infrastructure using providers with established enterprise security and compliance programs. Supabase provides the PostgreSQL database, authentication, storage and backend application services. Cloudflare provides DNS, CDN, network and API traffic delivery, TLS termination and edge/network security. Lovable hosts and operates the Asyrx application and delivers Asyrx service email.

Certain infrastructure providers supporting Asyrx maintain certifications such as SOC 2 Type II and ISO 27001. These certifications apply to the respective provider and do not constitute certifications of Asyrx or Thought Media™.

Asyrx applies additional application-level controls for tenant isolation, API security, access management, auditability and data minimization, described below.

Asyrx only represents certifications, attestations, and independent security assessments after they have been completed and verified. Qualified enterprise customers may contact Asyrx regarding current security documentation and deployment requirements.

Asyrx is designed to support enterprise privacy and data-protection obligations, including applicable GDPR requirements where relevant to customer processing, PIPEDA and applicable Canadian provincial privacy legislation, and applicable U.S. state privacy laws. Enterprise customers can execute the Asyrx Data Processing Addendum, which incorporates recognized international transfer mechanisms where applicable. Asyrx does not use advertising, marketing-analytics or behavioural-tracking technologies.

Asyrx is designed to evaluate structured action metadata. It generally does not require complete prompts, complete conversations, or copies of entire enterprise datasets.

• Preferred inputs: agent identifier, target system, normalized action type, financial value, number of records affected, destination, data classification, environment, reversibility, privilege changes, and relevant contextual metadata.
• Do not send passwords, authentication credentials, session tokens, or private cryptographic keys.
• Do not send full payment-card information, and avoid protected health information, biometric data, or other highly sensitive information unless expressly supported and contractually approved.
• Send identifiers, classifications, counts and contextual attributes rather than unnecessary content.

• Customer data is stored in PostgreSQL with row-level security enabled and organization-scoped policies, so one organization cannot read another organization’s records.
• Application access requires authentication; server-side functions resolve the caller’s identity and organization before any data access.
• Role-based permissions separate organization owners, administrators, developers, analysts, reviewers and read-only users.
• Access restrictions are enforced server-side and at the data layer, not by hiding user-interface elements.
• Behavioural baselines are computed per organization and remain tenant-isolated. Asyrx does not train cross-customer models on private customer content.

• API keys are generated as high-entropy secrets, shown in full only at creation, and stored as SHA-256 hashes rather than recoverable values.
• Test and live keys are separated by prefix, and test activity is kept out of live behavioural baselines and production usage records.
• Keys support scopes, rotation, expiry and revocation, and record last-used time for review.
• Requests are validated with strict schema validation and return structured error codes.
• Rate-limit configuration, idempotency keys and per-request request IDs are implemented for the public assessment API.
• Authorization headers, API keys and other sensitive values are redacted from request logs.
• Outbound webhooks are signed with HMAC-SHA256 over a timestamped payload and retried with exponential backoff so receivers can verify authenticity and reject replays.

Public web and API traffic is served over TLS, terminated at the Cloudflare edge. Data at rest is protected using the encryption capabilities of the underlying infrastructure providers. Enterprise customers should confirm data-region and encryption requirements during procurement.

Asyrx records material events such as API-key creation, rotation and revocation, agent registration, policy changes, action submission, assessment completion, human-review outcomes and webhook configuration, along with API request logs containing endpoint, status, latency, environment and request ID. Each assessment stores the risk-engine and policy versions used, so historical results remain interpretable and engine changes never silently rewrite prior decisions.

Asyrx separates demo, test and live assessment contexts at the data layer. Demo and test activity is flagged and excluded from live baselines and production usage metering. Enterprise Sandbox access is granted through a reviewed request process rather than open self-service sign-up.

• Code and configuration changes are maintained in source control with review and testing appropriate to the change.
• Risk-engine changes create a new engine version rather than altering historical assessment logic.
• The deterministic engine is covered by automated tests so scoring behaviour is reproducible.
• Dependencies and third-party services are reviewed and updated on a risk-based basis.

Asyrx investigates security events, contains incidents, assesses affected systems and data, notifies customers where required, preserves relevant evidence and remediates confirmed issues. Security reports should be sent to info@asyrx.com with the subject line “Security Vulnerability Report.”

Asyrx relies on selected providers for infrastructure, database, authentication, network delivery and service email. The current production list is maintained on the Sub-processors page. Vendor security is part of the Asyrx shared-responsibility model.

Asyrx provides risk intelligence about proposed AI-agent actions. Enterprise security architecture works best when that intelligence sits alongside the controls the customer already owns.

• Asyrx: action assessment, scoring, reason codes, behavioural and policy context, recommended controls, audit records of assessments, and the security of the Asyrx service itself.
• Customer: identity, permissions and authorization; final execution of actions; agent configuration; target-system security; business policies and approval workflows; backups and recovery procedures; and applicable regulatory requirements.

Qualified enterprise customers may request security documentation, architecture discussions, a DPA, and sub-processor information. Requests should be sent to info@asyrx.com or raised through the enterprise access process.