This policy explains how Runeward Labs (we, us or our) handles personal data in connection with our products runeguard and runebox, our websites, enquiries and support. Sections 1 and 2 describe runeguard deployments and monitoring. Website, download and support interactions for both products are covered by this policy.
Privacy enquiries: [email protected]. Product support and security incident reports: [email protected]. Please do not send passwords, access tokens or unnecessary sensitive information.
1 Our role and the responsibility of your organisation
We act as a controller for business contact information, enquiries, subscription administration, billing, our website operations and security, and administration of our relationship with customers and suppliers. Where information is collected from a business representative, it may come from that person, their organisation or an authorised introduction.
Where we provide hosted monitoring or otherwise process information on a customer's behalf, the customer ordinarily determines the purposes of its endpoint monitoring, identity directories, findings, incident investigations, configured response actions and substantive support materials. We process that information under its instructions. A customer may itself be a processor, in which case we act as its subprocessor. Account identity used solely to administer the customer's authorised users is also subject to those instructions; information we independently require for our own commercial relationship is controller information. The purpose and actual processing determine the role. The deployment boundaries below apply.
Your employer or other organisation must explain its monitoring purposes, legal basis, administrators, retention, integrations and workplace safeguards. Its activation of a feature is not automatically your consent under data protection or communications law. Contact the organisation for requests about its monitoring data; we will assist it as required. Our own legal duties continue to apply.
Local-only use. runeguard Community can scan without cloud enrollment. Results are not sent to us merely because runeguard is installed. Where endpoint data remains entirely under the customer's control and neither we nor a provider acting on our behalf processes it, supplying the software alone does not make us its processor. The customer's local processing remains subject to its own obligations.
Customer self-hosting. Enrolled devices send configured telemetry to the customer's runeguard Cloud. The customer controls that environment and its hosting arrangements; we do not acquire routine access merely by licensing the software. If the customer submits data or authorises us to process it for support or another service, we process it only within the scope of that support or service and the customer's instructions.
Runeward Labs hosted services. Enrolled devices synchronising with our hosted runeguard Cloud send the baseline security and device-operation data described in section 2.1. We process this through our service and contracted infrastructure, including OVHcloud, even if no staff member reads it. Separate content opt-ins control the additional categories described below; switching them off does not disable baseline telemetry.
Download, update, catalogue, website, account and support connections are separate data flows. They may involve request and network records or information a person submits, even when endpoint scanning is local-only. A customer's chosen integrations can also send data to its own recipients. The relevant categories are described in sections 3 and 6.
2 Information processed by runeguard
The categories below describe supported versions and configurations, not features running on every device. A local read or inspection is processing even without retention or upload, but does not itself mean Runeward Labs receives that information or acts as its processor. Our role depends on the deployment and actual operations in section 1. Device identifiers, hashes and redacted excerpts may still identify a person, particularly when linked to a directory or device assignment.
2.1 Security events and device operations
For enrolled devices that synchronise with a configured runeguard Cloud, baseline security and device-operation telemetry is separate from the optional content and human-activity settings. It can include device and installation identifiers, customer-selected labels, operating system and software versions, public signing keys and certificates, enrollment and coverage state, tamper signals, event times, detection identifiers and policy decisions. AI-attributed activity can include process identifiers and correlators, executable names and signing information, file or credential event types, hashed paths or session identifiers, destination hosts or IP addresses, ports, protocols and traffic counts where supported.
Inventory and posture checks can include AI tools, MCP servers and tools, package or extension names, runtime and model information, permission settings and configuration findings. The intended standard telemetry excludes unrestricted prompt, document and tool-output bodies. Customer-selected labels, hostnames, metadata and legacy text fields may nevertheless contain personal or confidential information. Hashing reduces exposure; it does not guarantee anonymity.
2.2 Local inspection
Supported tool hooks inspect supplied tool inputs and outputs locally to evaluate policy and detect threats or secrets. Scanners may read selected configuration, manifest, lock or credential-related files. Optional screenshot hashing reads image bytes locally. These activities must not be understood as a promise that the software never reads file contents or prompts. Retaining or uploading excerpts is a separate operation governed by the content settings below.
2.3 Optional human-to-AI sharing checks
The human AI sharing setting is off by default. When enabled, supported integrations can inspect prompts for secrets or configured data identifiers; check attachments; record screenshot, image-paste or upload event digests and AI destinations; hash files in a configured screenshot folder; and record AI application origins and daily usage counts. These event collectors do not upload screenshot image files or create screen recordings. The setting is distinct from permission to retain session content.
2.4 Optional session content
Session content collection is off by default. If the organisation enables it, or authorises an incident-specific escalation, supported integrations can upload redacted excerpts of prompts, tool inputs and outputs, assistant replies, permission requests and observed outcomes. Excerpts are limited to 2,048 bytes each; available content depends on what the relevant integration supplies. This is not a complete recording of every session.
Recognised secrets are redacted before upload and checked again at intake. Redaction is not guaranteed to remove every identifier, secret, health detail, confidential statement or other sensitive information. Authorised customer administrators can view eligible excerpts. Incident escalation is time limited, scoped and recorded; a second approver is required by default but can be changed by the organisation's configuration. Current SIEM export event types exclude session content. Other authorised disclosures, such as a customer copying information it can lawfully view or submitting material for support, have their own privacy consequences.
2.5 Other optional observations and identity mapping
Separate settings can enable remote-session metadata and document sensitivity labels. Remote-session observation can record supported meeting or remote-access application names and timing, including some non-AI processes; it does not record meeting audio, participants or screen content through that collector. Document-label inspection reads supported sensitivity metadata locally and reports mapped classes or label digests rather than extracting general document bodies.
The Console, manual people directory and configured identity integrations can process names, work email addresses, user and external identity identifiers, account status, job titles, departments, roles and groups. Device activity may be associated with a named individual through these mappings. An organisation should verify mappings before relying on them in an investigation.
3 Website, contacts, accounts, support and assessments
Enquiries, trial requests and feedback can include a person's name, business email, organisation, company size, requested plan, proposed account name and the message submitted. We use this information to respond, evaluate requests and administer the relationship. Providing it is voluntary, but we may be unable to answer or set up a requested service without the necessary contact details.
Accounts and service security can generate sign-in records, session identifiers, administrative actions, role changes and network or technical logs. Billing administration can involve invoice details, a business address, tax information, payment status and commercial correspondence. We do not require customers to send payment-card details in support cases. If we introduce a payment collection service, we will explain the provider and information collected before you use it.
Support records can contain case descriptions, replies, actors, attachments and their names, severity, assignment, status and history. Please minimise or redact source code, personal documents and secrets before submitting them. Staff may create internal notes; subject to applicable legal disclosure rights, their text is restricted to staff, while the customer's history can show that a note was added and by whom. Access to a support case is separate from permission to inspect endpoint telemetry.
A public URL assessment can process a submitted hostname, evidence of host control, target addresses, public HTTP response headers, TLS information, selected redacted response excerpts or hashes, findings and request-derived rate-limit identifiers. It may inspect accidentally exposed public resources. Do not submit a site you are not authorised to assess. A report link can grant access to its holder and should be treated as confidential. A redacted excerpt can still contain personal data.
Hosting, edge, delivery and update services may process IP addresses, user-agent details, request paths, timestamps and security or delivery events. Sections 6 to 8 describe recipients, international safeguards and retention. We do not treat a hashed IP address as necessarily anonymous.
4 Cookies and similar storage
We do not use advertising cookies or third-party analytics on our marketing pages. Other Runeward Labs services use the functional storage described below. The Console uses session and security cookies; sign-in integrations can use short-lived binding cookies. Public URL verification uses browser session storage. Necessary storage supports authentication, fraud prevention or a service the user requests.
The Console session cookie __Host-guard_console has a maximum eight-hour life and a 30-minute server inactivity limit. The __Host-guard_sso sign-in binding cookie lasts up to 10 minutes. Staff-only operator cookies have separate four-hour session and 10-minute sign-in limits. Public URL verification uses sessionStorage under runeward-url-scan, ending with the browser session or earlier removal. The Console can remember the organisation address in localStorage under runeward.console.address; it has no automatic expiry and remains until forgotten or cleared. This remembered address is not sent as runeguard telemetry. We will explain any additional non-essential tracking before introducing it and obtain consent where required. Browser controls can remove or block storage, but doing so may prevent authentication or interrupt a requested assessment. Separate rules apply to endpoint access and electronic marketing.
5 Purposes and legal bases
Where the GDPR applies to our controller activities, the following purpose-specific bases apply. Where other data protection laws apply, we assess the corresponding lawful grounds, including section 25 of the NDPA referenced in section 12. A legal basis does not remove the duties of fairness, necessity, minimisation or transparency.
| Purpose | Data used | GDPR basis and limits |
|---|---|---|
| Respond to a business enquiry and manage a corporate relationship | Business contact details and correspondence | Article 6(1)(f), our legitimate interest in responding and administering business relationships, subject to a balancing assessment. Article 6(1)(b) applies only where necessary for a contract with the individual or their requested pre-contract steps. |
| Provide accounts and fulfil requested services | Necessary account, contact and service administration records | Article 6(1)(b) for an individual's own contract; Article 6(1)(f) for administering a corporate relationship. Customer-directed monitoring remains governed by the customer's legal basis and instructions. |
| Secure systems and investigate abuse | Access, technical and administrative logs | Article 6(1)(f), protecting systems, customers and information against misuse, using proportionate access and retention. |
| Maintain accounts and satisfy legal requirements | Invoice, tax, transaction and legally required records | Article 6(1)(c) only for applicable EU or Member State obligations. Other legal duties, including duties under our domestic law, are assessed under their own law and an appropriate GDPR basis where needed. |
| Send optional marketing or use non-essential tracking | Contact preferences and any disclosed tracking data | Consent where required, including applicable electronic-marketing rules; otherwise only a permitted and assessed legitimate-interest basis. You can object to direct marketing at any time. |
| Handle disputes and legal claims | Relevant relationship, security and case records | Article 6(1)(f), establishing or defending legal rights, subject to necessity and safeguards. Any special-category processing also needs a separate applicable condition. |
Under the NDPA, necessary business relationship administration, proportionate security and legal-claims processing rely on legitimate interests under NDPA section 25(1)(b)(v), subject to section 25(2). Necessary performance of a contract with the individual or their requested preliminary steps relies on section 25(1)(b)(i). Applicable domestic legal duties rely on section 25(1)(b)(ii). Consent-based optional activities rely on section 25(1)(a) and the requirements in section 26. An additional condition is assessed under section 30 for sensitive personal data. These grounds are applied to the corresponding purposes in the table, rather than treating consent as a condition of every service.
We do not use customer telemetry for targeted advertising, sell it, or share it for cross-context behavioural advertising. We do not use personal data processed for customers to train, fine-tune or improve models for our own or third-party purposes. Providing the service on the customer's instructions, including local security analysis, is distinct from model training. Staff must not place customer material into external AI tools unless an expressly authorised, properly contracted processing arrangement permits it.
The service is intended for security, not employee productivity scoring or determining employment eligibility. Rules can automatically flag, allow, block or escalate an action; authorised customers may also initiate response actions. Such actions can affect access or work. They require proportionate configuration and human review where legally required. A customer must assess any use involving solely automated decisions with legal or similarly significant effects; installing runeguard does not make that use lawful.
6 Recipients and disclosures
We disclose data only as necessary to authorised personnel, contracted infrastructure and business-service providers, customer-designated recipients, professional advisers, or authorities where legally required. Recipients can include hosting and backup providers, email delivery and mailbox services, and any approved support or operational provider. A customer's chosen identity provider, SIEM, webhook or notification destination may be its own recipient rather than a subprocessor we engage.
We use OVHcloud for hosted infrastructure. Where we engage it to process personal data on a customer's behalf, it acts as our subprocessor; for data we process as controller, its relevant hosting role is processor. Using an infrastructure provider does not transfer our own responsibilities to that provider. A customer's independently contracted self-hosting provider is not our subprocessor merely because it hosts runeguard.
We assess compulsory requests, disclose only what the law requires, and notify the affected customer or individual where lawful. Cross-border authority requests are also assessed under applicable transfer restrictions. If our business is reorganised or transferred, information may pass to an appropriate successor subject to applicable law, confidentiality and notice requirements; it does not become available for unrestricted new purposes.
7 Processing locations and international safeguards
Hosting, support and other authorised processing may involve more than one jurisdiction. Storage and administrative access do not necessarily occur in the same place. Hosting in Europe, including the European Economic Area (EEA), does not by itself mean all processing or access stays in the EEA.
Before making a transfer restricted by the GDPR, we require an applicable adequacy decision or a valid Article 46 safeguard, with assessments and supplementary measures where required. Where a destination is not covered by an applicable adequacy decision, the required alternative safeguard must be established. The 2021 EU transfer standard contractual clauses must be eligible for the particular importer and processing; they are not a universal answer for processing already directly subject to Article 3. You may request information about, or an appropriately redacted copy of, applicable safeguards using our privacy contact.
Outbound transfers subject to the NDPA are separately assessed under sections 41 to 43 and applicable regulatory requirements. An EU safeguard does not automatically satisfy another applicable transfer regime. Customer-configured exports and self-hosted deployments also require an appropriate assessment by the relevant controller or operator.
8 Retention and deletion
We retain information we process under section 1 only for a documented purpose and period, considering the service requested, legal duties, security needs and valid legal holds. The schedule below concerns those records; it does not attribute customer-only local or self-hosted storage to us. A plan's activity-history period is not a maximum for every service record. The customer chooses shorter available retention where appropriate.
| Category | Retention and disposal rule |
|---|---|
| Startup activity history | Normally 90 days; supported customer setting 30 to 90 days. A default 30-day grace applies after a move to Startup or loss of long-history entitlement. Incident-linked material and the newest collector record can remain under separate rules below. |
| Enterprise activity history | No automatic expiry currently. Records remain until deleted or covered by an agreed retention instruction, subject to applicable legal holds. Customers can request deletion through their administrator or our privacy contact. |
| Session content excerpts | Configured 1 to 90 days, default 30 days; access also depends on a valid content basis. Disabling collection does not necessarily erase every existing copy immediately. |
| Inventory daily counts and MCP activity | Default 200 days; current supported bounds 186 to 730 days. A shorter contractual period requires a separately implemented disposal process. |
| Incidents, audit, response, export and chain records | These are not all subject to routine activity-history expiry. Retention depends on whether an incident or investigation remains open, whether evidence is needed to verify an action, and whether a legal obligation or claim requires preservation. Holds are reviewed when those circumstances change. |
| Accounts, directories and device records | Retained while needed to provide and secure the account or device relationship, including access revocation, replay prevention and resolution of outstanding obligations. Directory removal does not necessarily remove related security evidence. |
| Enquiries, feedback, trials and mailbox copies | Pending requests remain while being assessed or answered. Decided trial requests normally have identifying fields removed after 90 days. Linked account records follow the account lifecycle; correspondence is retained where needed to resolve the request, document the resulting relationship or address a dispute. |
| Support cases, attachments and staff notes | Retained to handle the case and relevant follow-up, document the support provided, and address related security issues or disputes. Closure alone does not automatically erase attachments, staff notes or separate email copies. |
| Public URL assessments | Reports normally 30 days; verification normally 24 hours if unproven or 30 days if proven; rate-limit identifiers normally one day. |
| Mail delivery queue | Payload removed after delivery or permanent failure; status and digest normally 14 days. Mailboxes are separate. |
| Infrastructure, access, security and update logs | Retention depends on the log's security or delivery purpose, investigation needs, the service configuration and applicable legal obligations. These logs do not all follow the activity-history periods above. |
| Billing and legally required records | Retained for the applicable tax, accounting or other statutory period, and longer only where a relevant legal hold requires preservation. |
| Backups and legal holds | Backup copies may remain until overwritten or expired under the relevant recovery cycle; access is restricted and applicable deletions are reapplied after restoration. Legal holds are limited to the relevant obligation or claim and reviewed periodically. |
Local device records and customer exports may remain under the customer's control and require separate disposal. We do not promise that a Console deletion erases copies a customer or other recipient has independently retained. We will explain any lawful refusal or limitation when responding to a deletion request.
9 Security
We use risk-appropriate safeguards including controlled access, device authentication, tenant restrictions, validation, transport protection and auditability. We limit authorised support access and require confidentiality. No product, redaction process or security control can eliminate all risk.
Encryption of particular credentials or an offline queue does not mean every local file or hosted database is end-to-end encrypted. Certifications or independent reports are claimed only where a current report and its scope are expressly identified.
10 Your rights and complaints
Depending on applicable law and the circumstances, you may request information or access, correction, erasure, restriction, a portable copy, or an objection to processing; withdraw consent prospectively; and challenge qualifying automated decisions. You may object to direct marketing without giving a reason. Withdrawing consent does not affect earlier lawful processing. We do not discriminate or retaliate for exercising a protected privacy right.
Contact [email protected] with enough information to locate the records. We use proportionate verification and do not request excessive identity documents. An authorised agent may act where permitted. We respond within the applicable statutory period, ordinarily one month under GDPR and commonly 45 days under US comprehensive laws, with any lawful extension explained. If a request is refused, we explain the reason and applicable review, appeal or complaint route. US residents may appeal a refusal through the same contact with the subject Privacy appeal where their state law provides that right. We explain the applicable appeal procedure and deadline. If an appeal is denied, we provide the information required by the relevant state law for a complaint to its Attorney General or other competent authority.
For customer-controlled data, we route the request to the customer and assist it; we do not independently disclose one organisation's data to an unverified requester. You can complain to the competent data protection authority, including the NDPC at ndpc.gov.ng where the NDPA applies and, where GDPR applies, the relevant supervisory authority where you habitually reside, work or believe an infringement occurred. You need not exhaust our internal process before using a statutory complaint or court remedy.
Where California law applies, covered information may include identifiers, employment or professional information, commercial records, internet or electronic activity, and sensitive information incidentally present in submitted content. The categories, purposes, sources and recipients are described above. We do not sell personal information or share it for cross-context behavioural advertising. Applicable access, correction, deletion, opt-out and sensitive-information rights depend on our role and the law's scope. If our practices change to require an opt-out or preference-signal mechanism, we will provide it and explain how to use it before the change.
11 Children, changes and further information
The services are intended for adults using them professionally, not for children. Customers must not deploy them for child monitoring or knowingly provide children's data without a separately approved lawful arrangement and the required safeguards. Contact us if information about a child has been submitted inappropriately so that we can assess removal and other required action.
We review this policy at least annually and update the date shown above when it changes and provide appropriate notice of material changes. A policy update cannot retroactively legitimise incompatible processing or replace consent, a contract amendment or another safeguard where required.
12 Legal references
Relevant provisions: GDPR Articles 3-6, 9, 12-22, 25, 27-28, 32-39 and 44-49; Nigeria Data Protection Act 2023 (NDPA), sections 2, 24-32 and 34-44; GAID 2025; and applicable US, employment, communications and electronic-marketing laws. This policy does not certify compliance.
General Data Protection Regulation · NDPA 2023 official text · NDPC General Application and Implementation Directive 2025 · European Commission transfer clause guidance · California Consumer Privacy Act · EEA supervisory authorities.