Hawi Agents — Security & Trust Policy

Last Updated: 23 August 2026 Effective Date: 23 August 2026

This Security & Trust Policy explains the security principles, technical and organisational safeguards, operational practices and customer responsibilities associated with the services provided by Hawi Inc, trading as Hawi Agents (“Hawi”, “Hawi Agents”, “we”, “us”, or “our”).

This document is intended to provide customers, prospective customers, security researchers, regulators and other interested parties with a high-level description of Hawi's approach to protecting information.

It should be read alongside our:

• Privacy Policy;
• Terms and Conditions;
• Cookie Policy;
• Acceptable Use Policy;
• Cancellation and Refund Policy;
• Data Processing Agreement, where applicable;
• Subprocessor List;
• and any applicable enterprise agreement or Order Form.

This page is a public security overview. It is not intended to disclose confidential security configurations, credentials, private infrastructure topology, exploit information or information that could reasonably weaken Hawi's security.

1. COMPANY DETAILS

Legal entity: Hawi Inc Trading name: Hawi Agents Registered office: [INSERT REGISTERED ADDRESS] Company number: [INSERT COMPANY NUMBER] Website: [INSERT FINAL PRODUCTION DOMAIN] Security contact: [INSERT SECURITY EMAIL] Privacy contact: [INSERT PRIVACY EMAIL] Legal contact: [INSERT LEGAL EMAIL]

2. SECURITY PRINCIPLES

Hawi's security programme is designed around the following principles:

1. defence in depth;
2. least privilege;
3. separation of customer data;
4. server-side authorisation;
5. secure credential handling;
6. minimisation of unnecessary data;
7. controlled Agent authority;
8. traceability of important operations;
9. secure third-party integration;
10. resilience and recovery;
11. vulnerability management;
12. incident response;
13. privacy by design;
14. secure defaults;
15. and continuous improvement.

No internet-connected service can guarantee absolute security.

Hawi therefore uses layers of controls intended to reduce both the likelihood and impact of a security incident.

3. SECURITY AND HAWI AGENTS

Hawi presents security considerations beyond those of a traditional website because authorised Agents may be capable of taking real-world actions.

Depending on customer configuration, Agents may be able to:

• read email;
• send communications;
• access files;
• create calendar events;
• interact with connected applications;
• make telephone calls;
• receive telephone calls;
• operate APIs;
• communicate with other Agents;
• respond to external events;
• initiate purchasing;
• interact with commerce systems;
• or perform other authorised operations.

Accordingly, Hawi security includes both conventional information-security controls and controls governing what Agents are permitted to do.

4. SECURITY IS SHARED

Security is a shared responsibility between Hawi, our infrastructure providers and our customers.

Hawi is responsible for security measures relating to the Hawi platform.

Customers are responsible for matters including:

• protecting their passwords;
• protecting their devices;
• maintaining secure connected accounts;
• selecting appropriate user roles;
• controlling Agent permissions;
• limiting purchasing authority;
• selecting appropriate approval policies;
• revoking former employees;
• securing API keys;
• and notifying Hawi promptly if compromise is suspected.

5. ACCOUNT ISOLATION

Hawi is designed around Accounts and Workspaces.

Customer information should be logically separated so that a user may access only resources that the user is authorised to access.

Access decisions may consider matters including:

• authenticated user identity;
• Account membership;
• Workspace membership;
• role;
• ownership;
• product access;
• administrator privileges;
• resource assignment;
• and explicit authorisation.

Authentication alone must not be treated as sufficient authorisation to access another customer's data.

6. WORKSPACE SECURITY

Workspaces provide a further logical boundary within an Account.

Where supported, Workspace controls may determine access to:

• Agents;
• files;
• boards;
• conversations;
• integrations;
• Agent memories;
• usage;
• analytics;
• shared resources;
• and other Workspace information.

Account-level ownership of a resource does not necessarily make that resource available to every Workspace.

7. DATABASE ACCESS CONTROLS

Hawi uses Supabase and PostgreSQL-based data services for significant portions of the platform.

Hawi's data architecture uses mechanisms including:

• database permissions;
• row-level security where appropriate;
• server-side access controls;
• private schemas;
• ownership checks;
• Account membership checks;
• Workspace membership checks;
• and privileged server-side operations

to restrict data access.

Customer-facing data access must not depend solely on hiding database identifiers.

8. ROW-LEVEL SECURITY

Row-level security (“RLS”) may be used to enforce data isolation directly within the database.

Where a database table is exposed through an application data API, Hawi's security standard is that access must be restricted according to the actual authorisation model.

A policy that merely checks whether a user is signed in is not sufficient where the relevant data is customer-specific.

Policies should validate the user's authority to access the relevant:

• Account;
• Workspace;
• resource;
• file;
• Agent;
• or other object.

9. SERVER-ONLY DATA

Certain information should not be directly accessible through ordinary browser roles.

Examples may include:

• pricing internals;
• infrastructure costs;
• payment-processing state;
• privileged billing state;
• credential references;
• execution authorisations;
• sensitive operational controls;
• fraud controls;
• creator payout accounting;
• internal retention controls;
• and other administrative data.

Where appropriate, Hawi places this information behind server-only controls or within private database structures.

10. AUTHENTICATION

Hawi uses authenticated sessions to protect private Account functionality.

Authentication controls may include:

• verified identity information;
• secure sessions;
• password controls;
• session expiry;
• session revocation;
• security challenges;
• phone verification where applicable;
• and additional verification for sensitive operations.

Hawi may increase authentication requirements when an action presents greater risk.

11. AUTHORISATION

Authentication answers:

“Who is this?”

Authorisation answers:

“What may this person do?”

Hawi treats these as separate security questions.

A valid signed-in session must not automatically grant access to every Hawi resource.

12. ADMINISTRATIVE PRIVILEGES

Administrative permissions may permit sensitive activities such as:

• managing members;
• issuing invitations;
• modifying roles;
• changing billing settings;
• assigning integrations;
• modifying Agent permissions;
• or managing Workspace access.

Hawi aims to restrict administrative operations to appropriately authorised users.

Sensitive administrative operations may also generate audit information.

13. ACCOUNT MEMBERSHIP

Business Accounts may distinguish between:

• owners;
• administrators;
• billing administrators;
• members;
• suspended members;
• users without product access;
• and other roles.

Permissions should be based on explicit role and product-access state rather than merely possession of an Account identifier.

14. INVITATION SECURITY

Account invitations may provide access to commercially or personally sensitive information.

Invitation systems should therefore use protections including:

• limited validity;
• revocation;
• secure invitation tokens;
• Account binding;
• role specification;
• Workspace assignment;
• and appropriate server-side validation.

Invitation tokens should not be treated as ordinary public identifiers.

15. AGENT PERMISSIONS

Agents should be given only the permissions reasonably necessary for their assigned work.

Permissions may include:

• reading information;
• sending communications;
• editing records;
• using particular integrations;
• using voice;
• accessing files;
• making purchases;
• or performing financial actions.

Higher-risk capabilities should be subject to stronger controls.

16. AGENT APPROVALS

Hawi may support approval requirements before an Agent carries out a sensitive operation.

Approval may be based on:

• action type;
• Integration;
• transaction amount;
• Workspace;
• destination;
• user;
• risk category;
• or another customer-defined policy.

An Agent should not be able to bypass a mandatory approval requirement simply by delegating the operation to another Agent.

17. FINANCIAL AUTHORISATION

Where an Integration may move money or initiate a financial action, Hawi may apply additional controls such as:

• explicit financial authorisation;
• transaction limits;
• approval requirements;
• spending breakers;
• provider verification;
• idempotency;
• and audit logging.

Financial authority should not be inferred merely because an Agent can access a connected application.

18. AUTOMATIC PURCHASING

Automatic purchasing is a high-impact capability.

Where supported, it should require explicit customer configuration.

Hawi may maintain records showing that automatic purchasing was enabled or disabled.

Customers should configure:

• maximum transaction values;
• approval thresholds;
• merchant restrictions;
• Agent permissions;
• and spending ceilings

appropriate to their risk tolerance.

19. SPEND CONTROLS

Hawi may use spending controls intended to limit unintended costs or transactions.

These may include:

• Account limits;
• Workspace limits;
• wallet limits;
• transaction limits;
• automatic-recharge caps;
• Agent limits;
• provider-level controls;
• and platform circuit breakers.

No spending control should be intentionally bypassed through repeated requests, Agent delegation or other circumvention.

20. EXECUTION AUTHORISATION

Paid or sensitive Agent execution may use server-generated execution authorisations.

Where employed, an execution authorisation may be:

• limited in scope;
• bound to specific claims;
• time limited;
• single use;
• and validated before execution.

This reduces the risk that possession of a general Account session alone authorises unrestricted external activity.

21. IDEMPOTENCY

Some external actions have consequences that should not be repeated accidentally.

Examples include:

• purchases;
• emails;
• financial actions;
• webhook processing;
• and other write operations.

Hawi may use idempotency identifiers and operation records to reduce the risk of duplicate execution during retries or infrastructure failures.

22. AGENT LOOP PROTECTION

Automated systems may accidentally enter repetitive loops.

Hawi may use:

• maximum execution limits;
• recursion controls;
• Agent handoff depth;
• duplicate-operation detection;
• workload controls;
• spend limits;
• and abnormal-behaviour detection

to reduce runaway activity.

Hawi may suspend an apparently looping run even where unused Credits remain available.

23. CREDENTIAL STORAGE

Third-party connector credentials are sensitive information.

Hawi's design separates customer connection identity from the permissions granted to individual Workspaces.

Where supported, provider credentials should be stored in protected server-side credential storage rather than copied into every Workspace.

Workspaces may receive permission to use an Account connection without receiving the underlying provider secret.

24. CUSTOMER CONNECTOR SECRETS

Connector secrets should not be exposed through ordinary browser-readable records.

Hawi may store references to protected secrets rather than raw secret values in application tables.

Access to actual credentials should be limited to trusted server-side execution paths that require them.

25. DEVELOPER API KEYS

Hawi developer credentials should be treated as secrets.

Where Hawi generates a developer secret, the secure design is to:

• display the raw secret only when necessary;
• store a one-way representation or protected equivalent where possible;
• support revocation;
• support rotation;
• identify credentials separately;
• and track appropriate usage.

Customers must not publish Hawi API keys in client-side applications or public repositories.

26. SECRET MANAGEMENT

Hawi should not intentionally commit production secrets to source control.

Sensitive values should be managed through appropriate secret or environment-variable systems.

Secrets should be:

• restricted by environment;
• available only to authorised services;
• rotated when compromised;
• and removed when no longer required.

27. SOURCE CONTROL

Source code access should be restricted to authorised development personnel.

Sensitive data, customer production data and production credentials should not be placed into repositories unless specifically required and appropriately protected.

Code changes should be reviewable and attributable.

28. SOFTWARE SUPPLY CHAIN

Hawi relies on third-party software packages and libraries.

Supply-chain security practices should include appropriate measures such as:

• dependency locking;
• controlled package installation;
• dependency review;
• vulnerability monitoring;
• patching;
• minimising unnecessary dependencies;
• and investigation of suspicious package behaviour.

29. SECURE SOFTWARE DEVELOPMENT

Security should be considered throughout software development.

Depending on the relevant component, this may include:

• design review;
• access-control review;
• input validation;
• type checking;
• testing;
• dependency analysis;
• secret detection;
• code review;
• deployment validation;
• and post-deployment monitoring.

30. SEPARATE ENVIRONMENTS

Hawi may maintain separate:

• development;
• preview;
• test;
• and production

environments.

Non-production environments should not be assumed to have authority over production customer data.

Production secrets should not be unnecessarily copied to development environments.

31. DEPLOYMENT SECURITY

Hawi uses Vercel infrastructure for portions of its frontend and backend deployment architecture.

Deployment controls may include:

• build isolation;
• protected preview environments;
• environment-specific configuration;
• encrypted connections;
• deployment logs;
• and controlled production promotion.

Provider capabilities and protections depend on the Hawi plan and configuration in use.

32. DATABASE INFRASTRUCTURE

Hawi uses Supabase infrastructure for database and related application services.

The Hawi Supabase project's primary database region is currently configured in London, United Kingdom (eu-west-2).

A selected primary database region does not mean that every Supabase support, security, control-plane or subprocessor activity necessarily occurs exclusively in that region.

33. ENCRYPTION IN TRANSIT

Hawi uses encrypted network connections for supported production communications.

TLS should be used for transmission of sensitive information between:

• users and Hawi;
• Hawi services;
• databases;
• and supported third-party providers

where available and appropriate.

34. ENCRYPTION AT REST

Hawi relies in part on infrastructure-provider encryption protections for stored data and backups.

Additional application-level protections may be applied to particularly sensitive information such as credentials.

Encryption does not replace access control.

35. PASSWORDS

Passwords must not be stored in plaintext.

Where an authentication provider handles password authentication, Hawi relies on the provider's password storage and security mechanisms rather than intentionally storing users' raw passwords in its application database.

36. PAYMENT SECURITY

Hawi uses Stripe for payment-related functionality.

Where Stripe-hosted or Stripe-controlled payment interfaces are used, sensitive card information is intended to be submitted to Stripe rather than intentionally stored as complete payment-card credentials within Hawi's application database.

Hawi may retain non-sensitive payment information necessary for:

• billing status;
• transaction reconciliation;
• subscription state;
• invoices;
• fraud handling;
• and accounting.

37. PAYMENT WEBHOOKS

Payment events must not be trusted merely because a request claims to come from a payment provider.

Provider webhook signatures or equivalent authentication should be validated before authoritative billing state is changed.

Webhook processing may use deduplication to reduce repeated processing.

38. BILLING ENTITLEMENTS

Paid access should be derived from trusted billing state rather than directly from browser-supplied claims.

Hawi may write billing entitlements following verified payment-provider events.

A client request alone should not be sufficient to grant itself a paid Plan.

39. AI MODEL PROVIDERS

Hawi may transmit information to approved model providers when necessary to fulfil Agent tasks.

Model access should occur through trusted server-side systems rather than exposing Hawi's provider credentials to end users.

Current Hawi metering configuration includes OpenAI and Anthropic model providers.

Customers should not assume that every Agent run necessarily uses the same model provider.

40. MODEL DATA MINIMISATION

Where practicable, Hawi should minimise information transmitted to model providers.

This may include:

• sending only information relevant to the task;
• reducing unnecessary context;
• avoiding unnecessary secrets;
• excluding unrelated Workspace information;
• and controlling which tools and resources an Agent can access.

41. HIDDEN REASONING

Hawi does not need to expose or retain a model's hidden chain-of-thought in order to provide ordinary Agent functionality.

Operational records may instead contain information such as:

• user instructions;
• visible responses;
• tool calls;
• execution state;
• and relevant system events.

42. VOICE SECURITY

Voice services may process:

• telephone numbers;
• call metadata;
• speech;
• transcripts;
• recordings where enabled;
• and follow-up actions.

Voice services may involve specialist communications or speech providers.

Hawi should minimise retention and provider access according to the feature and applicable legal requirements.

43. CALL RECORDING

Where call recording is available, recording should not automatically be assumed lawful in every context.

Customers remain responsible for appropriate:

• notice;
• consent;
• lawful basis;
• employee policy;
• and telecommunications compliance.

Access to recordings or transcripts should be restricted according to appropriate Account and Workspace permissions.

44. FILE SECURITY

Hawi may allow private Workspace file uploads.

File security may include:

• private storage;
• metadata access controls;
• file-type restrictions;
• size restrictions;
• malware scanning;
• validation;
• quarantine;
• content-disposition controls;
• and restricted download access.

Hawi may reject files reasonably suspected of posing a security risk.

45. MARKETPLACE SECURITY

Marketplace Agents or modifiers can create additional supply-chain risk.

Hawi may therefore use:

• submission review;
• code or artefact analysis;
• permission review;
• malware detection;
• quarantine;
• moderation;
• behavioural controls;
• and listing removal.

Passing a security review does not guarantee that Marketplace content contains no defects.

46. AUDIT EVENTS

Hawi may maintain audit information relating to important actions.

Examples can include:

• administrative changes;
• Agent execution;
• approval events;
• integration operations;
• billing activity;
• privacy requests;
• resource transfers;
• and other sensitive state changes.

Audit records may be protected from ordinary modification where integrity is important.

47. IMMUTABLE FINANCIAL RECORDS

Certain financial or usage accounting records may use append-only or immutable designs.

Rather than silently editing historical usage, corrections may be represented through additional correcting entries.

This improves:

• traceability;
• reconciliation;
• dispute investigation;
• and fraud detection.

48. LOGGING

Hawi may maintain security, application and operational logs necessary for:

• troubleshooting;
• security monitoring;
• abuse investigation;
• billing reconciliation;
• incident response;
• and reliability.

Logs should avoid unnecessary storage of secrets and highly sensitive content.

49. LOG ACCESS

Access to production logs should be limited to authorised personnel with a legitimate operational need.

Logs should not be treated as a convenient alternative database for storing customer secrets.

50. MONITORING

Hawi may monitor system health and security indicators including:

• errors;
• unusual authentication;
• provider failures;
• abnormal execution;
• webhook failures;
• rate-limit events;
• infrastructure utilisation;
• and potentially malicious activity.

Monitoring is intended to help detect both security and reliability problems.

51. RATE LIMITING

Hawi may enforce rate limits to protect:

• authentication;
• APIs;
• database services;
• Agents;
• external providers;
• and platform availability.

Rate limits may vary according to:

• endpoint;
• Plan;
• Account;
• provider;
• risk;
• and current capacity.

52. CIRCUIT BREAKERS

Hawi may use circuit breakers to stop or restrict requests where continued execution could create abnormal cost, provider instability or broader platform risk.

Circuit breakers are a resilience and security mechanism rather than a customer entitlement.

53. PROVIDER FAILURE ISOLATION

Where possible, failures affecting one provider or subsystem should not unnecessarily compromise unrelated parts of Hawi.

Hawi may use:

• retries;
• queues;
• fail-closed behaviour;
• circuit breakers;
• provider isolation;
• and workload controls

to reduce cascading failure.

54. BACKUPS

Hawi relies on backup capabilities provided through appropriate infrastructure providers and may maintain additional recovery controls as needed.

Backups may be subject to:

• encryption;
• access controls;
• retention schedules;
• separate storage;
• and restoration procedures.

55. DISASTER RECOVERY

Hawi maintains or intends to maintain procedures appropriate to the risks of the Services for responding to significant infrastructure failures.

Recovery arrangements may consider:

• data restoration;
• deployment restoration;
• provider outages;
• credential recovery;
• and continuity of critical Services.

Unless separately agreed in writing, this Policy does not create a guaranteed recovery-time objective or recovery-point objective.

56. VULNERABILITY MANAGEMENT

Hawi's vulnerability-management process is intended to include:

1. identification;
2. assessment;
3. prioritisation;
4. remediation;
5. verification;
6. and documentation

of material security vulnerabilities.

Priority should reflect factors including:

• exploitability;
• customer-data exposure;
• privilege impact;
• internet exposure;
• and potential business consequences.

57. SECURITY UPDATES

Hawi may deploy security fixes without advance notice where delay could increase risk.

Customers should not rely on a particular internal implementation remaining unchanged.

58. PENETRATION TESTING

Hawi may conduct or commission appropriate security testing.

Customers are not authorised to conduct destructive testing against Hawi without written permission.

Enterprise customers may request available security-assurance information subject to:

• confidentiality;
• availability;
• contractual terms;
• and reasonable security restrictions.

59. THIRD-PARTY SECURITY

Hawi evaluates third parties proportionately to:

• the information they process;
• the access they receive;
• the criticality of the service;
• geographic processing;
• contractual protections;
• and available security information.

Higher-risk providers should be subject to stronger review.

60. SUBPROCESSORS

Where Hawi acts as a processor for a customer and appoints another processor to process Customer Personal Data on Hawi's behalf, that provider may constitute a Subprocessor.

Hawi maintains a separate Subprocessor List.

Where required by applicable data-protection law and Hawi's DPA, Hawi will:

• obtain general or specific customer authorisation;
• impose appropriate contractual data-protection obligations;
• provide notice of material new Subprocessors;
• and provide an appropriate process for objections.

61. CUSTOMER-SELECTED CONNECTORS

A provider does not automatically become a Hawi Subprocessor merely because a customer chooses to connect that provider to Hawi.

For example, where a customer directs Hawi to communicate with the customer's:

• email provider;
• CRM;
• calendar;
• commerce service;
• project-management service;
• or other third-party account,

that service may instead be a customer-selected third party or independent controller.

The legal role depends on the processing arrangement.

62. INTERNATIONAL TRANSFERS

Some Hawi providers process information outside the United Kingdom.

Where Hawi is required to implement a lawful transfer mechanism, we may rely on mechanisms such as:

• UK adequacy regulations;
• EU adequacy decisions where relevant;
• the EU Standard Contractual Clauses;
• the UK International Data Transfer Addendum;
• the UK International Data Transfer Agreement;
• or another legally recognised safeguard.

63. DATA MINIMISATION

Hawi aims to collect and retain only information reasonably necessary for:

• providing the Services;
• meeting legal obligations;
• security;
• billing;
• fraud prevention;
• support;
• and legitimate product operation.

A technically available field should not automatically be collected merely because it can be collected.

64. RETENTION

Different data categories may require different retention periods.

Hawi may maintain documented retention schedules for categories including:

• Account records;
• billing records;
• Agent logs;
• audit information;
• files;
• security records;
• privacy requests;
• and communications.

Retention may be suspended by a legal hold.

65. DELETION

Where deletion is required, Hawi may remove information from active systems according to the applicable retention process.

Some information may remain temporarily in:

• backups;
• legally required records;
• fraud records;
• security logs;
• or legal holds

until deletion is permitted or technically completed.

66. PRIVACY REQUEST SECURITY

Data-subject requests can themselves create security risks.

Hawi may therefore verify the identity and authority of a requester before:

• providing personal information;
• correcting records;
• deleting data;
• or transferring information.

Verification should be proportionate to the sensitivity of the requested data.

67. SECURITY INCIDENTS

A security incident may include a confirmed event resulting in unauthorised:

• access;
• disclosure;
• alteration;
• destruction;
• or loss

of protected information.

Not every failed login, blocked attack or unsuccessful scan constitutes a personal-data breach.

68. INCIDENT RESPONSE

Hawi's incident-response process is intended to cover:

1. detection;
2. triage;
3. containment;
4. investigation;
5. eradication;
6. recovery;
7. legal assessment;
8. notification where required;
9. and post-incident improvement.

69. PERSONAL-DATA BREACHES

Where Hawi becomes aware of a personal-data breach, Hawi will assess:

• affected systems;
• affected data;
• affected people;
• likely consequences;
• containment;
• required notifications;
• and remediation.

Where Hawi acts as a processor, we will notify the relevant controller without undue delay where required by applicable law and our DPA.

Where Hawi acts as a controller, we will comply with applicable regulatory and individual-notification obligations.

70. INCIDENT COMMUNICATION

Security incident communications may initially contain incomplete information.

Hawi may provide updates as additional facts become available.

Hawi will not intentionally delay a legally required notification solely because every detail of an investigation has not yet been established.

71. SECURITY RESEARCHERS

We welcome good-faith reports of potential security vulnerabilities.

Reports should be sent to:

[INSERT SECURITY EMAIL]

Please include:

• affected service;
• vulnerability description;
• reproducible steps;
• potential impact;
• relevant request or response information;
• and suggested remediation where available.

72. RESPONSIBLE DISCLOSURE

Security researchers must not:

• access another customer's data beyond what is essential to establish a vulnerability;
• modify another customer's data;
• destroy data;
• perform denial-of-service testing;
• extort Hawi;
• publicly disclose secrets;
• install persistent malware;
• or use a vulnerability for personal gain.

If sensitive information is encountered accidentally, stop further access and report the issue.

73. SECURITY SAFE-HARBOUR

Where Hawi publishes a formal vulnerability-disclosure programme in the future, any safe-harbour protection will apply only according to that programme's express conditions.

This Policy alone does not grant unrestricted permission to test Hawi systems.

74. CUSTOMER SECURITY OBLIGATIONS

Customers should:

• use strong, unique credentials;
• protect authentication factors;
• review Account membership;
• remove former employees;
• minimise Agent permissions;
• rotate exposed API keys;
• use approvals for high-risk operations;
• configure spending limits;
• secure connected applications;
• and report suspicious behaviour promptly.

75. CUSTOMER ENDPOINTS

Hawi cannot protect information after it has been legitimately downloaded to an insecure customer-controlled device.

Customers remain responsible for:

• device encryption;
• operating-system updates;
• malware protection;
• physical security;
• browser security;
• and appropriate endpoint controls.

76. CONNECTED ACCOUNTS

The security of a Hawi Integration depends partly on the connected provider.

If a connected account is compromised independently of Hawi, an attacker may be able to misuse permissions granted through that account.

Customers should revoke or reconnect compromised Integrations promptly.

77. CUSTOMER API APPLICATIONS

Developers integrating with Hawi are responsible for securely handling:

• Hawi API credentials;
• customer data returned by APIs;
• webhook secrets;
• stored tokens;
• and downstream systems.

The existence of Hawi's security controls does not secure a customer's own application automatically.

78. NO SECURITY GUARANTEE

Hawi does not promise that:

• security incidents are impossible;
• all vulnerabilities will be detected before exploitation;
• every third-party provider will always be available;
• or every malicious request will be blocked.

Security is an ongoing risk-management process.

79. CERTIFICATIONS

Hawi will only claim a security or compliance certification when that certification has actually been issued to Hawi and remains applicable.

The certifications, reports or attestations of a Hawi provider do not automatically constitute certifications of Hawi.

For example, a SOC 2 or ISO certification belonging to a cloud, model or communications provider should not be represented as Hawi's own certification.

80. SECURITY DOCUMENTATION

Business and Enterprise customers may request additional security information where available.

Depending on the material requested, Hawi may require:

• an NDA;
• verification of the requesting organisation;
• contractual restrictions;
• or another appropriate confidentiality arrangement.

Sensitive penetration-test findings and architecture details may not be publicly distributed.

81. CHANGES TO THIS POLICY

Hawi may update this Security & Trust Policy as:

• architecture changes;
• new providers are added;
• security controls improve;
• regulations change;
• new features launch;
• or new risks emerge.

Material changes will be reflected by updating the date at the beginning of this Policy.

82. CONTACT

For security questions:

Security: [INSERT SECURITY EMAIL]

For privacy questions:

Privacy: [INSERT PRIVACY EMAIL]

For legal enquiries:

Legal: [INSERT LEGAL EMAIL]

For general support:

Support: [INSERT SUPPORT EMAIL]

SCHEDULE 1 — SECURITY CONTROL SUMMARY

SCHEDULE 2 — CUSTOMER SECURITY CHECKLIST

Customers should:

• Use a unique password for Hawi.
• Protect all authentication factors.
• Review Account administrators regularly.
• Remove users who no longer require access.
• Give Agents the minimum permissions necessary.
• Require approval for high-risk Agent actions.
• Configure appropriate purchasing limits.
• Configure appropriate usage limits.
• Review connected third-party applications.
• Disconnect integrations that are no longer required.
• Never expose API keys in frontend code.
• Rotate credentials immediately after suspected exposure.
• Verify recipients before high-impact automated communications.
• Use appropriate call-recording notices.
• Review Marketplace permissions before installation.
• Report suspected Account compromise to Hawi immediately.

SCHEDULE 3 — INFORMATION HAWI WILL NOT REQUEST THROUGH ORDINARY SUPPORT

Hawi personnel should not need you to provide:

• your full payment-card number;
• your CVC/CVV;
• your password;
• another service's password;
• authentication recovery codes;
• seed phrases;
• or other unnecessary authentication secrets

through ordinary support messages.

If somebody claiming to represent Hawi requests such information, treat the request as suspicious and contact Hawi through an official channel.

SCHEDULE 4 — SECURITY ASSURANCE PRINCIPLES

Hawi's security programme should continuously work toward:

Confidentiality — information is available only to authorised parties.

Integrity — information and operations cannot be improperly modified.

Availability — Services remain reasonably resilient and recoverable.

Accountability — sensitive operations are attributable and reviewable.

Least Privilege — users, Agents and systems receive only required authority.

Fail Securely — uncertainty around authorisation should not become unrestricted access.

Minimise Blast Radius — failure of one service should not unnecessarily compromise unrelated systems.

Assume Automation Can Fail — autonomous Agents require limits, approvals and traceability.

Protect Secrets — credentials are treated differently from ordinary application data.

Verify External Consequences — important third-party write actions require appropriate confirmation and replay protection.

END OF SECURITY & TRUST POLICY