Privacy Policy.

1. Overview & Scope.

1.1 Who we are, and what “the ASG ecosystem” means. Agentic Secure Group Inc., a Delaware C-Corporation doing business as “Bolde” (“Bolde,” “Company,” “we,” “us,” or “our”), is the contracting party and the operator of the Service. It operates the website at bolde.ai and provides the Bolde sovereign AI platform (the “Service”). Throughout this Policy, “the ASG ecosystem” means, collectively: Agentic Secure Group Inc.; Agentic Secure Inc.; Mojave Research Inc., which is the verified Microsoft publisher of the Bolde applications under Microsoft Partner ID (MPN) 7086299; IP Strategy & Advocacy; Agent Xero LLC; and Agentic Trace LLC — and their respective parents, subsidiaries, affiliates, predecessors, successors and assigns, and their respective officers, directors, employees, agents, contractors and licensors. Where this Policy states a limitation, disclaimer, allocation of responsibility, or release, that provision runs to and may be enforced by every member of the ASG ecosystem, and not to Agentic Secure Group Inc. alone. Where this Policy states an obligation owed to you, Agentic Secure Group Inc. is responsible for its performance. This Privacy Policy explains how we handle personal information across two clearly distinct contexts described in Section 2.

1.2 United States only. Bolde serves United States customers and visitors only. The Service and this website are not directed to, offered to, or intended for individuals located in the European Union, the United Kingdom, or other jurisdictions governed by the GDPR, and we do not knowingly process the personal data of EU/UK data subjects. This Policy is written to comply with applicable U.S. federal and state privacy and data-security laws, including the California Consumer Privacy Act as amended by the California Privacy Rights Act (“CCPA/CPRA”) and the California Privacy Protection Agency’s regulations on automated decisionmaking technology, risk assessments, and cybersecurity audits; the Colorado Privacy Act (“CPA”) and its rules, including the Colorado biometric amendments (HB 24-1130); the Colorado Artificial Intelligence Act (SB 24-205); the Washington My Health My Data Act; the Texas Data Privacy and Security Act and the Texas Capture or Use of Biometric Identifier Act; the Illinois Biometric Information Privacy Act (“BIPA”); the New York SHIELD Act; and the comparable consumer-privacy laws of Virginia, Connecticut, Utah, Oregon, Montana, and Delaware.

1.3 Effective date. This Policy is effective as of July 25, 2026, applies to the Service as it operates in production today, and supersedes all prior versions. A dated revision log is at Section 19.

1.4 How we write this document. We state what the Service can actually do, not what would be most reassuring. Where a control exists today, we state it as a binding commitment you can hold us to. Where a safeguard does not yet exist, we call it forthcoming and we never describe it as in place. We do not make a capability-negative claim — a statement that the Service “cannot,” “does not,” or “never” does something — without tying it to a named application registration and a defined scope. Every permission count in Section 16 is derived from the registrations themselves rather than transcribed, and an administrator can verify each of them directly against the applications in their own tenant.

2. Two Data Contexts — Read This First.

Your rights and our obligations differ depending on which data is involved. We separate them throughout this Policy.

• Context A — Website & Marketing Data (Bolde as a business/controller). When you visit bolde.ai, subscribe to Bolde Updates, request access, or opt in to text messages, Bolde determines the purposes and means of processing your personal information and acts as a “business” (CCPA/CPRA) and “controller” (other state laws). Sections 3 through 14 govern this context.
• Context B — Customer Environment Data (Bolde as a service provider/processor). When a customer organization connects its productivity, collaboration, identity, device-management, security, and compliance systems to the Service, Bolde ingests and processes that organization’s data on the customer’s documented instructions to provide the Service, and — where the customer enables administrative capability — takes actions within that environment. In this context the customer is the “business”/“controller” and Bolde is a “service provider” (CCPA/CPRA) / “processor” (other state laws) in every mode, including administrative modes. Sections 15 through 18 govern this context, which is also governed by our Data Processing Addendum (“DPA”).

2.1 Five classes of data in Context B. “Customer Data” alone no longer describes what the Service handles. We distinguish five classes, all processed as a service provider/processor and all covered by the commitments in Sections 15 and 16:

• Customer Content. Mail and mailbox content, calendars, contacts, files and document libraries, sites, chats and channel messages, tasks and notes, and the personal information contained in them.
• Control-Plane Objects. Tenant configuration rather than user content: directory roles and role assignments, conditional-access and other policies, application registrations and service principals, domains, groups, administrative units, custom security attributes, and Privileged Identity Management assignments. Control-Plane Objects are not ordinary Customer Content, they frequently identify named administrators and named users, and they are treated as a distinct category with their own handling rules.
• Device and Endpoint Management Data. Managed-device inventory and identifiers, hardware and operating-system attributes, enrollment and ownership designation, compliance and configuration state, assigned user, and the record of privileged device operations.
• Security Signals. Threat, incident, identity-risk, sign-in-risk, audit-log, and configuration-monitoring telemetry.
• Agent Identity Records. Entra Agent ID identities and blueprints, the credentials associated with them, the permissions assigned to them, and the log of actions taken under them.

2.2 If you are an individual whose data reached us through a customer. If your employer or another organization connected its systems to Bolde and your personal information was processed as part of that organization’s environment, that organization — not Bolde — is the controller responsible for that data and for authorizing the actions the Service takes. Please direct privacy requests to that organization; we will support the organization in responding as required by Section 15 and our DPA. Section 17 is written specifically for you, including if your personal device is enrolled in your employer’s device management.

3. Website & Marketing Data We Collect (Context A).

3.1 Categories and sources. In the website/marketing context we collect only the following, primarily directly from you:

• Identifiers and contact data. Name, business email address, company name, job title, and — if you opt in — mobile phone number. Collected when you subscribe to Bolde Updates, submit a request-access or contact form, or correspond with us.
• Commercial / interest data. The product interest, use case, or message content you choose to include in a form or email.
• Cookieless aggregate analytics. Limited technical signals (e.g., page views, referring source, coarse device/browser type, approximate region) collected in aggregate and not used to identify or track you across other sites. We do not use third-party advertising cookies, cross-site trackers, third-party web analytics, third-party hosted fonts, third-party error-monitoring, or similar third-party telemetry on this website.
• SMS consent records. If you opt in to text messages, we retain a record of your consent, the number, and the opt-in event.
• Administrative consent records. If you are an administrator who grants consent to a Bolde application registration, we retain a record of the consent event: the consenting user principal name, the tenant, the application, the permission manifest consented to, and the timestamp. This record exists to evidence the scope and terms of the authorization.

3.2 Biometric identifiers. The Bolde website does not collect, capture, or use biometric identifiers or biometric information (such as fingerprints, faceprints, voiceprints, or retina/iris scans) from website visitors. Section 12 states our position for the Service precisely, including what directory metadata about a user’s authentication methods is and is not.

3.3 No sensitive-data collection on the website. We do not ask for, and you should not submit through website forms, Social Security numbers, financial-account credentials, precise geolocation, health data, or other sensitive personal information. Sensitive personal information may be present in Context B, where the customer authorizes it — see Sections 11 and 15.

4. How We Use Website & Marketing Data.

We use the personal information in Section 3 to:

• Provide requested communications. Send Bolde Updates and respond to access requests, inquiries, and correspondence.
• Send text messages you consented to. Deliver SMS only to numbers that opted in; message and data rates may apply; reply STOP to opt out and HELP for help. We do not sell or share SMS opt-in data, and consent is not shared with third parties for their marketing.
• Operate and secure the website. Maintain, debug, and protect the site using aggregate analytics and server logs.
• Evidence authorization. Retain administrative consent records so that both parties have a durable, verifiable record of what was authorized, by whom, and when.
• Comply with law and enforce our terms. Meet legal obligations and protect our rights, users, and systems.

4.1 No website profiling or automated decisions about you. We do not use website/marketing data to make decisions that produce legal or similarly significant effects about you, and we do not engage in cross-context behavioral advertising.

5. Disclosures, and Our No-Sale / No-Share Commitment.

5.1 We do not sell or share your personal information. This is a binding commitment. Bolde does not sell personal information for monetary or other valuable consideration, and does not “share” personal information for cross-context behavioral advertising, as those terms are defined under the CCPA/CPRA and analogous state laws. This applies to every category in Section 3 and to all five Context B classes in Section 2.1, including Control-Plane Objects, Device and Endpoint Management Data, Security Signals, and Agent Identity Records. We have not sold or shared personal information in the preceding twelve months.

5.2 Limited service-provider disclosures. We disclose website/marketing data only to vendors that process it on our behalf under contract and only as needed to provide their service to us (for example, email delivery, SMS delivery, and our sovereign hosting infrastructure). These recipients are contractually barred from using the data for their own purposes.

5.3 Legal and corporate disclosures. We may disclose personal information within the ASG ecosystem where necessary to operate, support, and secure the Service under this Policy; when required by law, subpoena, or legal process; to protect rights, safety, and security; or in connection with a merger, acquisition, financing, or sale of assets, subject to this Policy. Where a legal demand seeks Context B data, we will, unless legally prohibited, notify the customer before responding so the customer can seek protective relief, and we will direct the requesting party to the customer as the controller.

6. Sovereign AI — No Base-Model Training; No Third-Party LLM in the Path.

6.1 No third-party LLM vendor. Bolde inference is sovereign. The Service runs on Company-controlled infrastructure using the Company’s proprietary models (Bolde-Small, the base model, and Bolde-Custom, the base model shaped by a customer’s approved workflows). No third-party large-language-model vendor (such as OpenAI, Anthropic, or Google) is in the production data path for processing your information or any Context B data class. This is a binding commitment, and we will not introduce a third-party model into that path without amending this Policy and giving affected customers advance notice under Section 19.1.

6.2 No base-model training on your data. As a binding commitment, Bolde does not use website/marketing personal information, Customer Content, Control-Plane Objects, Device and Endpoint Management Data, Security Signals, or Agent Identity Records to build, train, or improve its general-purpose base or foundation models. The only model adaptation permitted is customer-scoped tuning of Bolde-Custom, performed solely within and for that customer’s sovereign deployment and only with that customer’s authorization. Any service-improvement activity is limited to aggregated and de-identified data and to operating, securing, and debugging the Service, and never to base-model training on identifiable data.

6.3 No Company use of control-plane or security data. As a binding commitment, Bolde does not use Control-Plane Objects or Security Signals for its own purposes. We do not use them to build threat-intelligence, benchmarking, scoring, or research products, and we do not aggregate them across customers except to produce data that is aggregated and de-identified in accordance with the de-identification undertaking in the DPA and that cannot reasonably be re-associated with any customer or individual. This commitment binds every member of the ASG ecosystem.

7. Retention.

7.1 Website/marketing data. We retain Bolde Updates subscriptions until you unsubscribe; SMS records for as long as you remain opted in plus the period required to evidence consent; access-request and inquiry data for as long as needed to respond and for a reasonable follow-up period; and aggregate analytics for limited rolling windows. Administrative consent records are retained for the term of the customer relationship and thereafter for the applicable limitations period, because they evidence the scope of an authorization on which both parties rely. We retain personal information only as long as necessary for the purposes described, to comply with law, resolve disputes, and enforce agreements, then delete or de-identify it.

7.2 Context B data. Customer Content, Control-Plane Objects, Device and Endpoint Management Data, Security Signals, and Agent Identity Records are retained per the customer’s instructions, the Order Form, and the DPA, and are returned or deleted on termination as described in Section 15.8.

7.3 Audit and approval records; immutability limits. Records evidencing that an administrative or destructive action was authorized and executed — the approving individual, the target list, the timestamp, and integrity values — are retained for the applicable limitations period so that the record survives any dispute about what occurred. The Bolde Keeper application (appId 117a680a-0085-4666-9219-61abe9139797) supports an audit record that is designed to be tamper-evident and, once written, not alterable. This is a real limit on deletion. If you have a valid deletion right and personal information about you appears in such a record, we commit to delete or de-identify every copy we can lawfully and technically delete, and to tell you specifically what remains in an immutable record and why. We do not treat “the record is immutable” as a general answer to a deletion request.

8. Information Security.

8.1 Safeguards. Consistent with the New York SHIELD Act and applicable state data-security requirements, we maintain a written information-security program with administrative, technical, and physical safeguards reasonably designed to protect personal information, including risk assessments, access controls and least-privilege, encryption in transit and at rest, audit logging, employee training, vendor oversight, and incident-response procedures. Our Security page describes the program in detail, including which controls are in place today and which are forthcoming. No method of transmission or storage is perfectly secure, and we cannot guarantee absolute security.

8.2 Breach notification. If a security incident affecting personal information occurs, we will notify affected individuals and regulators as required by applicable state breach-notification laws. Under California Civil Code § 1798.82, we will notify affected California residents in the most expedient time possible and without unreasonable delay, consistent with the legitimate needs of law enforcement and any measures necessary to determine the scope of the breach and restore the reasonable integrity of the data system; California law sets no fixed 30-day individual-notice deadline. Under Colorado’s breach-notification statute (Colo. Rev. Stat. § 6-1-716), we will notify affected Colorado residents in the most expedient time possible and without unreasonable delay, and in no event later than 30 days after determining that a breach occurred. Under the New York SHIELD Act, we will notify affected New York residents in the most expedient time possible and without unreasonable delay. Where Bolde processes Context B data as a processor, we will notify the customer without undue delay so the customer can meet its obligations, as set out in the DPA.

8.3 Destructive-action incident notice. Separately from Section 8.2, and as a binding commitment, if the Service executes a destructive action — including a remote wipe or retire of an enrolled device, a bulk deletion, or a revocation of access — that was erroneous, exceeded the customer’s authorization, or affected an asset it should not have affected, we will notify the customer within 24 hours of determining that this occurred and will provide the target list, the approval record, and the restoration options available. This notice obligation applies whether or not the event also qualifies as a security incident. Report suspected vulnerabilities to security@bolde.ai.

9. Your Privacy Rights (Website & Marketing Data).

9.1 Rights available depending on your state. Subject to your state of residence and applicable exceptions, you may have the right to:

• Know / access. Confirm whether we process your personal information and obtain a copy and details of categories, sources, purposes, and recipients.
• Correct. Request correction of inaccurate personal information.
• Delete. Request deletion of personal information we collected from you, subject to the immutability limit disclosed in Section 7.3.
• Portability. Obtain a portable copy of personal information you provided.
• Opt out. Opt out of sale, sharing for cross-context behavioral advertising, and profiling in furtherance of decisions producing legal or similarly significant effects. As stated in Section 5, we do not sell or share, and we do not conduct such profiling on website data.
• Limit use of sensitive personal information. Direct us to limit use of sensitive personal information to permitted purposes. We do not collect sensitive personal information on the website.
• Non-discrimination / non-retaliation. Exercise your rights without unlawful discrimination or retaliation.
• Appeal. In states that provide it (e.g., Colorado, Virginia, Connecticut, Texas, Oregon, Montana, Delaware), appeal our decision on your request.

9.2 How to exercise. Submit a request by emailing privacy@bolde.ai. We will verify your request, generally respond within the timeframe required by your state’s law (commonly 45 days, extendable as permitted), and require no fee for a first reasonable request. You may use an authorized agent where the law permits; we may require proof of authorization and verification of your identity.

9.3 Opt-out preference signals. Where required, we honor recognized universal opt-out mechanisms (such as Global Privacy Control). Because we do not sell or share, such signals do not change our handling but are respected as a matter of compliance.

10. State-Specific Disclosures.

10.1 California (CCPA/CPRA). In the 12 months prior to the effective date we collected the categories in Section 3 for the purposes in Section 4, disclosed them only to service providers as described in Section 5.2, and did not sell or share personal information or use or disclose sensitive personal information beyond permitted business purposes. California residents have the rights in Section 9, including the right to limit sensitive personal information (not applicable to website data), and may exercise them via privacy@bolde.ai. Where Bolde acts as a service provider (Context B), it processes Customer Content, Control-Plane Objects, Device and Endpoint Management Data, Security Signals, and Agent Identity Records only as permitted by the CCPA service-provider terms in Section 15.5 and the DPA. Bolde’s service-provider role does not change when the customer enables administrative capability: administrative actions are processing carried out on the customer’s documented instruction, and Bolde does not determine the purposes or means of that processing.

10.2 Colorado (CPA, biometric amendments, and the Colorado AI Act). Colorado residents have the access, correction, deletion, portability, opt-out, and appeal rights in Section 9. Under the Colorado biometric amendments (HB 24-1130), see Section 12 — Bolde does not collect biometric identifiers from Colorado residents in either context, so the Act’s notice, consent, and retention-schedule obligations do not attach to Bolde as a controller; where a customer’s own systems contain biometric identifiers, the customer is the controller. Regarding the Colorado Artificial Intelligence Act (SB 24-205): in the website/marketing context, Bolde does not deploy a high-risk artificial-intelligence system that makes, or is a substantial factor in making, a consequential decision about you. Where a customer configures the Service’s AI, agentic, or administrative capabilities in a manner that could constitute a high-risk system — including automated actions affecting employment status, access to systems or facilities, or access to essential services — the customer is the deployer responsible for consumer notice, the duty of care to avoid algorithmic discrimination, and impact-assessment obligations; Bolde supports customers with documentation of the system’s intended uses, known limitations, and monitoring consistent with its developer/deployer-support role. We are tracking the Colorado AI Act’s current effective-date posture and will adjust as the law and its effective date are finalized.

10.3 Washington (My Health My Data Act). In Context A, Bolde does not collect consumer health data as defined by RCW 19.373.010, does not operate any website feature designed to collect it, and does not implement a geofence around any facility that provides in-person health-care services. In Context B, Bolde does not seek consumer health data and the Service is not designed to identify, infer, or derive health status. However, a customer’s connected mail, files, collaboration channels, HR systems, or Purview and eDiscovery repositories may contain information meeting the Act’s broad definition of consumer health data, and the compliance and eDiscovery capabilities described in Section 16 can surface such information in the course of a customer-directed search, hold, or export. Where that occurs, Bolde processes it solely as a processor on the customer’s documented instructions, applies the heightened handling in Section 11.2, and does not sell it. The customer is the regulated entity responsible for any consumer-health-data notice, consent, and authorization obligations for data in its own systems.

10.4 Texas (TDPSA and CUBI). Texas residents have the access, correction, deletion, portability, opt-out, and appeal rights in Section 9. Bolde does not sell personal data, sensitive data, or biometric identifiers, and therefore does not display the notices required by Tex. Bus. & Com. Code §§ 541.102(b)–(c). Under the Texas Capture or Use of Biometric Identifier Act (Tex. Bus. & Com. Code § 503.001), Bolde does not capture a biometric identifier for a commercial purpose in either context — see Section 12.

10.5 Illinois (BIPA). See Section 12 for a precise statement of what the Service does and does not do with respect to biometric identifiers and biometric information as defined by 740 ILCS 14/10. BIPA provides a private right of action and statutory damages that are not subject to any contractual cap; we therefore state our position narrowly and precisely rather than broadly.

10.6 Virginia, Connecticut, Utah, Oregon, Montana, and Delaware. Residents of these states have the rights afforded by their respective consumer-privacy laws (access, correction where provided, deletion, portability, and opt-out of targeted advertising, sale, and certain profiling), and an appeal right where provided. We do not engage in targeted advertising or sale of personal information. Oregon residents may request a list of specific third parties to which we disclosed personal information. Exercise any of these rights via privacy@bolde.ai.

10.7 New York (SHIELD Act). We maintain the reasonable safeguards described in Section 8 to protect New York residents’ private information and follow SHIELD breach-notification requirements.

11. Sensitive Data Handling.

11.1 Website context. We do not collect sensitive personal information from website visitors and do not use it for inferring characteristics.

11.2 Customer context. In Context B, sensitive personal information can reach the Service through several routes: a connected HR or workforce system (for example, Social Security numbers, dates of birth, and home addresses); mailbox, file, and chat content, which the Bolde Connect registration can read and write; the compliance, eDiscovery, and subject-rights-request capabilities in the Bolde Control registration, which are designed to locate exactly the regulated content a customer is looking for and can therefore surface health, financial, legal, precise-location, immigration-status, union-membership, and similarly regulated information; and custom security attributes, which a customer may populate with sensitive values. Bolde commits to treat all such data as sensitive, to process it only on the customer’s authorization and documented instructions to provide the Service, to apply heightened access controls and logging, and never to use it for base-model training (Section 6) or for any purpose outside the direct provision of the Service. Full terms are in Section 15 and the DPA.

11.3 Compliance tooling is a sensitivity multiplier, and we treat it that way. eDiscovery and subject-rights-request capabilities are not ordinary read scopes. They can search across an entire tenant, place and release holds, and export content in bulk. Bolde commits to restrict access to these capabilities to personnel with a documented operational need, to log every use, and to make that log available for customer review on request. These capabilities are carried by the Bolde Control registration only. A customer that does not want the Service to hold them can decline consent to Bolde Control or restrict its assignment; ingestion and content analysis do not require them. Declining Bolde Control does not, however, withhold every governance permission — see Section 16.4.

12. Biometric Data — Precise Scope Statement.

12.1 Website. The Bolde website does not collect, capture, or use biometric identifiers or biometric information from visitors.

12.2 The Service. The Service does not capture, store, or use biometric identifiers or biometric information as defined by BIPA, 740 ILCS 14/10. Metadata indicating whether a user has enrolled a biometric authentication method — for example, a directory attribute recording that a user has registered Windows Hello for Business or a platform authenticator — is not a biometric identifier or biometric information. The Bolde Control registration (appId ba2d80a5-2b27-470f-905e-827f2630af75) holds directory and authentication-method scopes that can read the fact of such enrollment. It cannot read the underlying biometric template, image, or measurement: Microsoft Graph does not expose that data through any permission, and Windows Hello biometric templates remain on the device’s secure hardware and are never transmitted to the directory or to Bolde. The same limit applies to the directory scopes held by the Bolde Connect registration.

12.3 Customer covenant. Customers must not configure the Service, or populate custom security attributes or any connected-system field, so as to transmit biometric identifiers or biometric information to Bolde. Bolde does not request, and has no product need for, such data.

12.4 Forthcoming — technical enforcement of the biometric boundary. A technical control that detects and blocks the ingestion of biometric identifiers into the Service, rather than relying on the customer covenant in Section 12.3, is forthcoming and is not in place today. Until it is, Section 12.3 is a contractual boundary, not an enforced one, and we say so rather than implying otherwise.

13. Children’s Privacy.

The website and Service are intended for businesses and individuals who are at least 18 years old and located in the United States. We do not knowingly collect personal information from anyone under 18. If you believe a minor has provided us personal information, contact privacy@bolde.ai and we will delete it.

14. Automated Decisionmaking, Profiling, and Agentic Action.

14.1 Website/marketing data. Bolde does not use website or marketing personal information to engage in automated decisionmaking technology (“ADMT”) or profiling that produces legal or similarly significant effects about you. There is no consumer-facing automated decision made about you from your website interactions.

14.2 Agentic action is different from analysis, and we do not blur them. In Context B the Service does not only analyze. Where a customer enables it, the Service can execute actions under an agent identity, and some of those actions have direct, immediate consequences for an identifiable person — for example, disabling or deleting an account, revoking sessions or access, changing a role assignment or conditional-access policy, or issuing a privileged device operation including a remote wipe or retire. Where a customer configures the Service so that such an action is initiated, or substantially informed, by an automated rule rather than by a contemporaneous human decision about the specific individual, that configuration may constitute automated decisionmaking or profiling producing legal or similarly significant effects under the CCPA/CPRA ADMT regulations, the Colorado AI Act, and comparable state laws.

14.3 Allocation of responsibility. The customer is the business/controller and deployer, and is responsible for any required ADMT pre-use notice, opt-out or human-review rights, logic and outcome disclosures, adverse-action notices, and risk and impact assessments. Bolde, as service provider/processor, commits to: (a) describe the general logic, the categories of personal information used, and the types of decisions and actions the features can support; (b) make available the functionality the customer needs to provide notice, honor opt-outs or appeals, and enable human review; (c) make available the attribution record for each agent action, including the identity under which it was taken and the governing rule; and (d) cooperate with the customer’s data-protection and risk assessments. Outputs are probabilistic and may be inaccurate or incomplete; they are informational only, are not professional, legal, financial, or medical advice, and must be reviewed by a qualified person before being relied upon. As phased ADMT transparency and opt-out obligations take effect (with key CCPA ADMT requirements applicable beginning in 2027), we will support customers in meeting them.

14.4 Human review is a customer configuration, not a platform guarantee. The Service supports human-in-the-loop review, and customers can configure it. Bolde does not represent that a human reviews every agentic action; whether a human does so depends entirely on how the customer configures the Service. Approval today operates at the level of a category of action rather than each individual instance of it — see Section 18.1.

15. Context B — Bolde as Service Provider / Processor.

15.1 Roles, in every mode. When a customer connects its systems, the customer is the business/controller and Bolde is the service provider (CCPA/CPRA) / processor (CPA and other state laws). This allocation does not change when the customer enables administrative or agentic capability. Administrative actions — including configuration changes, agent-identity lifecycle operations, and privileged device operations — are processing carried out on the customer’s documented instruction, evidenced by the customer’s administrative authorization and the applicable Order Form. Bolde does not determine the purposes or means of that processing. This processing is governed by the customer’s agreement and our Data Processing Addendum, which controls in the event of any conflict with this Section.

15.2 What is ingested, and sources. Into the customer’s own private, sovereign Bolde deployment, the Service ingests data from the customer’s connected systems via those systems’ interfaces. Depending on the permissions the customer grants, this can include: mail and mailbox content; calendars and contacts; documents, files, and sites; messaging and collaboration channels, including private, group, and meeting chat; tasks and notes; directory users, groups, roles, and administrative units; Control-Plane Objects including policies, application registrations, service principals, domains, custom security attributes, and Privileged Identity Management assignments; Device and Endpoint Management Data from the customer’s device-management system; Security Signals including audit logs, threat and incident data, and identity-risk signals; compliance, eDiscovery, and subject-rights-request data; Agent Identity Records; and, via a connected HR or workforce system, HR, employment, and organizational data that can include sensitive personal information (e.g., SSN, date of birth, address). Sources are the customer’s connected services and the individuals who use them.

15.3 Read and act — accurate scope. Bolde provides five product modes: Console (human-in-the-loop ask/review/approve/trace), Analyst (sourced analysis over the data), Scouts (watch for changes), Operator (performs repeatable work within the customer’s approved rules), and Auditor (immutable record/audit trail). In the operate and administer modes the Service does not merely read. Within the scopes the customer authorizes, it can send and draft email; create, update, and delete calendar events; read, write, and delete files and site content; read and post to messaging and collaboration channels, including private chat; create, modify, disable, and delete directory objects including users, groups, group memberships, and organization properties; create, modify, and delete role assignments, domains, and conditional-access and other policies; create, modify, and delete application registrations and their credentials; create, enable, disable, delete, and restore agent identities and modify their blueprints and credentials; run compliance, eDiscovery, and subject-rights-request operations including holds and exports; and execute privileged device-management operations including remote wipe and retire of an enrolled device. Section 16 states which registration carries which of these capabilities, and Section 16.4 states which of them survive a decision to decline the administrative application. The customer’s administrator controls consent and can revoke it at any time in the customer’s own tenant, without Bolde’s cooperation.

15.4 Customer control and customer responsibility. The customer’s administrator decides which application registrations to consent to, which permissions to grant, which rules Operator may act within, and which individuals may approve administrative and destructive actions. The customer is responsible for having the authority and the consents necessary to connect its systems and data, to enroll and manage the devices it enrolls, and to authorize actions affecting its personnel — including where a device is personally owned. See Section 18.3.

15.5 CCPA service-provider commitments. With respect to personal information made available by a customer in any of the five classes in Section 2.1, Bolde and every member of the ASG ecosystem that handles it:

• No sale; no sharing. Does not sell, and does not share for cross-context behavioral advertising, such personal information.
• Purpose limitation. Does not retain, use, or disclose it for any purpose other than the specific services performed for the customer, or as otherwise permitted by the CCPA, and not outside the direct business relationship.
• No combination. Does not combine it with personal information from other sources except as the CCPA permits (e.g., to detect security incidents, prevent fraud, or debug) and as the customer’s use case directly supports.
• No model training. Does not use it to build, train, or improve Bolde’s general base/foundation models (Section 6); customer-scoped Bolde-Custom tuning occurs only with customer authorization within the customer’s deployment.
• No Company use of control-plane or security telemetry. Does not use Control-Plane Objects or Security Signals for Company purposes, including threat-intelligence, benchmarking, or research products (Section 6.3).
• Certification. Understands these restrictions and certifies that it will comply with them.

15.6 Subprocessors. Bolde uses a limited set of subprocessors consisting of Company-controlled sovereign compute and hosting infrastructure to operate the Service. The customer’s own connected productivity, collaboration, identity, device-management, security, compliance, and HR or workforce systems are the customer’s own providers that the customer connects to Bolde — they are not Bolde’s subprocessors. Bolde imposes data-protection obligations on its subprocessors no less protective than those in the DPA, remains responsible for their compliance, and provides the customer notice of, and the ability to object to, new subprocessors as described in the DPA. The current subprocessor list is maintained under the DPA.

15.7 Assisting the customer. Bolde will, taking into account the nature of the processing, assist the customer in responding to verified consumer requests, in fulfilling security and breach-notification duties, and in conducting data-protection and risk assessments, all as further specified in the DPA. Where a customer uses the Service’s own subject-rights-request capabilities to respond to a request directed at the customer, the customer remains the controller of that response.

15.8 Return, deletion, and credential deprovisioning. On termination or at the customer’s instruction, Bolde will return or delete Context B data as provided in the DPA, subject to any retention required by law and the immutability limit in Section 7.3. On termination, suspension, or customer request, Bolde will deprovision the agent identities and credentials it holds for that customer within the period stated in the DPA and will provide written attestation on request. Independently of Bolde’s action, the customer can revoke consent and disable or delete the associated service principals and agent identities in its own tenant at any time, unilaterally.

15.9 Individual requests about Context B data. If you are an individual seeking to exercise rights over data held by Bolde as part of a customer’s environment, please contact the relevant customer organization, which is the controller. If you contact us at privacy@bolde.ai, we will refer your request to the appropriate customer and support their response. If your request concerns a device action taken against a device you personally own, read Section 17 first — and contact us in any event, because we want that report.

16. What the Deployed Bolde Applications Can Actually Do.

16.1 Why this section exists. A customer’s administrator sees the requested permissions on the Microsoft consent screen at the moment of consent. This section states the same information in plain language, before anyone reaches a consent screen, so that the authorization is informed. All Bolde application registrations are publisher-verified under Microsoft Partner ID (MPN) 7086299, held by Mojave Research Inc., which is the publisher of record for the applications and a member of the ASG ecosystem. Every count below is derived from the registrations’ declared permission manifests and consented role assignments as of the “Last updated” date, and each is independently verifiable by an administrator against the applications in their own tenant. Where a count in an earlier draft of this Policy was wrong, it is corrected here and the correction is recorded in Section 19.2.

16.2 Customer-facing (multi-tenant) applications. These are the registrations that appear on a customer’s consent screen. A customer may consent to some and not others.

• Bolde Connect — User Sign-In & Data Access (appId 98b0f1c8-eaf1-4f43-9255-1ace882e270e). 307 application permissions and 93 delegated permissions. It is commonly described as the content plane, and that description alone would understate it. Bolde Connect also carries governance-grade directory and identity write permissions: Application.ReadWrite.All, Directory.ReadWrite.All, User.ReadWrite.All, Group.ReadWrite.All, GroupMember.ReadWrite.All, Organization.ReadWrite.All, and IdentityRiskyUser.ReadWrite.All. Of its 307 application permissions, 80 end in .ReadWrite.All. Application.ReadWrite.All permits adding credentials to application registrations in the tenant, including registrations more privileged than Bolde’s own; combined with Directory.ReadWrite.All, a customer should evaluate consent to Bolde Connect as conferring administrative authority over directory objects and as a privilege-escalation path. Its content permissions include read, write, and send access to mailbox content (Mail.Read, Mail.ReadWrite, Mail.Send); read and write access to private, group, and meeting chat (Chat.Read.All, Chat.ReadWrite.All); read and write access to files and sites (Files.ReadWrite.All, Sites.ReadWrite.All); and read and write access to calendars (Calendars.ReadWrite). It also includes 33 delegated Entra Agent ID scopes for user-context agentic actions, which are bounded by the rights of the signed-in user and cannot exceed them. Its application-only agent permissions number 14: thirteen are manager-scoped or read-scoped (.ManagedBy, CreateAsManager, .Read.All variants) and the fourteenth is AgentIdUser.ReadWrite.IdentityParentedBy, which is write authority scoped to agent identities parented to this application rather than tenant-wide. This registration holds no tenant-wide application-only agent write authority — a statement about Bolde Connect only.
• Bolde Control — Tenant & Agent Governance (appId ba2d80a5-2b27-470f-905e-827f2630af75). 236 application permissions declared, 234 consented, plus six delegated scopes (Files.ReadWrite.All, Sites.ReadWrite.All, Files.Read.All, Sites.Read.All, User.Read, offline_access) that give it content write reach in a signed-in user’s context in addition to its administrative reach. This is the administrative plane and it is the most consequential consent a customer gives. It includes directory role management (RoleManagement.ReadWrite.Directory), application lifecycle (Application.ReadWrite.All), domain management (Domain.ReadWrite.All), and conditional-access policy management (Policy.ReadWrite.ConditionalAccess); the Entra Agent ID lifecycle across 34 roles, including creating agent identities, enabling and disabling them, deleting and restoring them, and adding or removing blueprint credentials; 18 Intune and device-management permissions including DeviceManagementManagedDevices.PrivilegedOperations.All, which permits remote wipe and retire of an enrolled endpoint; 26 Purview, eDiscovery, and subject-rights-request permissions; 7 attribute-based access-control permissions over custom security attributes; and 38 Privileged Identity Management permissions. Two permissions in this registration — AgentCard.Read.All and AgentCard.ReadWrite.All — are declared but are not grantable, because Microsoft has them disabled in preview; they confer no capability today.
• Bolde Ingest — M365 Content (appId eb9a1494-2237-4722-99c8-d305a652dabf). Four application permissions, all read-only — Mail.Read, Calendars.Read, Sites.Read.All, and User.Read.All — plus a single delegated User.Read scope. Bolde Ingest is the only Bolde application whose application permissions are entirely read-only. A customer that wants ingestion with no write, no directory, and no administrative capability should consent to Bolde Ingest alone.
• Bolde Keeper — Immutable Audit Anchor (appId 117a680a-0085-4666-9219-61abe9139797). A public client registration supporting the tamper-evident audit record described in Section 7.3. It holds no client secret or certificate credential and no Microsoft Graph application-only permissions. It does hold six delegated permissions — Mail.ReadWrite, offline_access, openid, profile, email, and User.Read — meaning that, in the context of a signed-in user and bounded by that user’s own mailbox rights, it is able to read, modify, move between folders, and delete mail in that user’s mailbox. It cannot send mail. We disclose that rather than describing this registration as inert, and because the name “Audit Anchor” would otherwise understate a mailbox-modifying permission. Because it holds no credential of any kind, it cannot presently authenticate as an application identity against a customer tenant; we note for completeness that the public-client designation is not by itself a durable technical guarantee, because it does not prevent a credential being added later. The guarantee here is the absence of a credential, which an administrator can verify directly.
• Bolde Sentry — Security Posture & Threat Operations (appId 3595ec54-f02e-4a89-9e72-7ab5fa33f04b). Forthcoming — not operational. This registration declares 103 application permissions covering threat intelligence and hunting, Defender for Identity, identity-risk signals, network-access policy, workload identity, unified audit-log query, configuration monitoring, and directory backup. As of the “Last updated” date it holds zero client secrets, zero certificates, and zero consented role assignments. Because it holds no credential of any kind, it cannot authenticate against any tenant, cannot access any customer environment, and processes no data. We can directly observe only our own tenant; the statement that it is not consented in any customer tenant rests on the fact that, without a credential, it cannot authenticate anywhere. Bolde Sentry consent and credentials do not exist today, and nothing in this Policy or in any agreement should be read as representing that they do. We describe it here for completeness rather than omitting it.

16.3 Internal-only (single-tenant) applications. Three further registrations — Bolde Core — ASG Internal Operations (400 application permissions), Bolde Meet — Teams Meeting Assistant, and Bolde Agent — Teams Bot — are single-tenant and operate only within Agentic Secure Group’s own Microsoft tenant. They are not multi-tenant, do not appear on any customer consent screen, and cannot be consented to or granted access in a customer tenant. They are listed here so that a customer reviewing our publisher profile is not surprised by their existence.

16.4 Consent is granular and revocable — and what declining Bolde Control does and does not withhold. Consent to one registration is not consent to another. A customer can consent to Bolde Ingest without Bolde Connect, and to Bolde Connect without Bolde Control. Declining Bolde Control withholds directory-role administration, conditional-access policy authority, domain modification, Intune privileged device operations including remote wipe and retire, Purview and eDiscovery and subject-rights-request authority, custom security attribute authority, Privileged Identity Management authority, and tenant-wide agent-identity lifecycle authority. Declining Bolde Control does not withhold every governance permission. Bolde Connect independently carries Application.ReadWrite.All, Directory.ReadWrite.All, User.ReadWrite.All, Group.ReadWrite.All, GroupMember.ReadWrite.All, and Organization.ReadWrite.All, so a tenant that consents to Bolde Connect alone has still conferred directory-object, user, group, and application-registration write authority. A customer seeking a deployment with no write capability of any kind should consent to Bolde Ingest alone. A customer administrator can review granted permissions, restrict assignment, and revoke consent entirely at any time from the customer’s own tenant, without Bolde’s involvement or cooperation. Revocation takes effect in the customer’s directory immediately.

16.5 Forthcoming — permission-by-permission disclosure at the consent moment. Presenting a per-application, permission-by-permission disclosure inside the Bolde product at the moment of administrative consent, captured as an assent artifact bound to the consenting user principal name and the exact permission-manifest hash, is forthcoming and is not in place today. Today, disclosure at the consent moment is what Microsoft’s consent screen presents, supplemented by this Section and our Security page.

17. Notice to Individuals in a Customer Organization.

17.1 Who this section is for. If your employer or another organization has connected Bolde to its systems, this section is written for you. That organization is the controller. Bolde acts on its instructions. But you are entitled to know, in plain terms, what that means for you.

17.2 What the Service may be able to see about you. Depending on which registrations your organization consented to (Section 16), the Service may be able to read your work mailbox content, your calendar, your files, and your private, group, and meeting chat; your directory record, group memberships, roles, and custom security attributes; sign-in and audit records and identity-risk signals about your account; your HR record if an HR system is connected; and inventory, compliance, and configuration data about any device enrolled in your organization’s device management, including a device you personally own. Content located by a compliance, eDiscovery, or subject-rights-request operation may be placed on hold or exported.

17.3 What the Service may be able to do to your account. Where your organization consented to Bolde Connect, the Service holds permissions that allow it to modify or disable your directory account, change your group memberships, and modify application registrations and their credentials in the tenant. Where your organization consented to Bolde Control, the Service can additionally be configured to change your role assignments, alter the conditional-access and other policies that govern your access, revoke your sessions, and delete your account.

17.4 Enrolled devices, including personally owned devices. Where your organization consented to Bolde Control, the Service holds the permission that allows a remote wipe or retire of a device enrolled in your organization’s device management. If the device you enrolled is one you personally own, a wipe can remove personal content stored on it. Bolde does not implement a technical restriction that prevents a full-device wipe of a device in a customer’s tenant that is flagged as personally owned; that restriction is forthcoming and is not in place today (Section 18.3). Whether such an action is ever taken, and under what conditions, is determined by your organization, which is responsible for having the authority and the consents to enroll and manage your device. We state this plainly because you cannot make an informed decision about enrolling a personal device without knowing it.

17.5 What you can do. Direct requests to know, access, correct, or delete your data to your organization, which is the controller. Ask your organization for its device-enrollment policy before enrolling a personally owned device. If you believe a device action was taken against you in error or without authority, contact privacy@bolde.ai as well as your organization — we will investigate, we will provide the attribution and approval record to the customer, and Section 8.3 requires us to notify the customer within 24 hours of determining that such an event occurred. Nothing in this Policy, and nothing in any agreement between any member of the ASG ecosystem and your organization, waives, limits, or releases any right you personally hold, and no such agreement binds you unless you personally agreed to it.

17.6 Forthcoming — individual device terms. An in-product End User Device Acknowledgment presented to and individually recorded from each person before their device is enrolled is forthcoming and is not in place today. Individually assented end-user device terms do not exist, and we do not represent otherwise. Today, the terms governing device management are between Bolde and your organization, and between you and your organization.

18. Controls That Are Forthcoming and Not Yet in Place.

The following safeguards are forthcoming and are not in place as of the “Last updated” date. We list them here, in the same document that describes the capabilities they would constrain, because describing the capability without disclosing the missing constraint would be misleading. Nothing in this Policy, on our website, in the Service, or in any agreement should be read as representing that any item in this Section exists today.

• 18.1 Per-instance approval gating — forthcoming. Authorization today operates at the level of a category of action, not each individual instance of it. Out-of-band confirmation by a designated administrative contact against a rendered, itemized target list; a mandatory delay window with an abort option; and an independent second approver above a threshold number of targets are forthcoming and are not implemented.
• 18.2 Pre-action snapshot and escrow — forthcoming. A mandatory snapshot or escrow of recoverable state taken before a destructive action, retained for a defined period and restorable at Bolde’s cost, is forthcoming and is not implemented. Until it is, a destructive action executed by the Service may be irreversible.
• 18.3 Technical block on wiping personally owned devices in a customer tenant — forthcoming. A code-level restriction that prevents a full-device wipe or factory reset of a device in a customer’s tenant that is flagged as personally owned, permitting only selective removal of work data, is forthcoming and is not implemented. See Section 17.4.
• 18.4 Individually assented end-user device terms — forthcoming. See Section 17.6.
• 18.5 Automatic honoring of native legal-hold state — forthcoming. An automatic technical block that queries a connected service’s native hold and preservation state and prevents a destructive action against an asset under hold — rather than relying on the customer to designate protected assets — is forthcoming and is not implemented.
• 18.6 Customer-tenant-held agent credentials — forthcoming. Agent credentials generated in and held by the customer’s own tenant, non-exportable, with Bolde holding only a federated credential the customer can revoke unilaterally, are forthcoming and are not implemented. Today, a customer’s unilateral revocation path is to revoke consent and disable or delete the service principal and agent identities in its own tenant (Sections 15.8 and 16.4).
• 18.7 Bolde Sentry — forthcoming. Not consented, no credential, not operational. Sentry consent and credentials do not exist. See Section 16.2.
• 18.8 Technical enforcement of the biometric boundary — forthcoming. See Section 12.4.
• 18.9 SOC 2 / ISO 27001 — forthcoming. Bolde does not hold either certification. See our Security page for current status.

19. Changes to This Policy; Revision Log.

19.1 How we change this Policy. We may update this Policy from time to time. We will revise the “Last updated” date and, for material changes, provide conspicuous notice (for example, by email to subscribers or a notice on the website). Changes are effective when posted unless we state otherwise. Where a change expands what the Service can do with a customer’s data, we commit to seek the customer’s affirmative acceptance rather than relying on continued use.

19.2 Revision log. We publish a dated record of substantive changes rather than revising silently.

• 2026-07-25. Materially expanded and corrected. Defined the ASG ecosystem (Section 1.1) and identified Mojave Research Inc. as the verified Microsoft publisher of record under MPN 7086299. Added the five Context B data classes (Customer Content, Control-Plane Objects, Device and Endpoint Management Data, Security Signals, Agent Identity Records) and confirmed that Bolde acts as a service provider/processor in every mode, including administrative modes. Added Section 16, stating the actual capability of each deployed application registration by name and appId. Within Section 16 we corrected several permission counts and disclosures that were wrong in the immediately preceding draft of this Policy: Bolde Connect’s delegated Entra Agent ID scopes are 33, not 41; its application-only agent permissions number 14, of which the fourteenth is AgentIdUser.ReadWrite.IdentityParentedBy rather than a manager- or read-scoped role; Bolde Control’s agent-lifecycle roles are 34, not 39, its Intune and device-management permissions are 18, not 20, its Purview, eDiscovery and subject-rights-request permissions are 26, not 25, and its Privileged Identity Management permissions are 38, not 41. We also newly disclosed that Bolde Connect carries governance-grade directory, user, group, application, and organization write permissions — so declining Bolde Control does not withhold every governance permission (Section 16.4) — that Bolde Control holds six delegated content scopes, that Bolde Ingest holds one delegated User.Read scope in addition to its four read-only application permissions, and that Bolde Keeper holds six delegated permissions including Mail.ReadWrite, which in a signed-in user’s context permits reading, modifying, moving and deleting mail in that user’s mailbox. Added Section 17, a direct notice to individuals in a customer organization, including enrolled personally owned devices. Added Section 18, an explicit list of safeguards that are forthcoming and not in place. Narrowed the biometric statement to a precise, defensible scope (Section 12) and added Colorado HB 24-1130 and Texas CUBI treatment. Added Washington My Health My Data Act, Texas TDPSA, and Illinois BIPA disclosures. Added the destructive-action incident notice (Section 8.3), the immutable-record deletion limit (Section 7.3), and the agentic-action ADMT analysis (Section 14). An earlier published version described the Service primarily as an ingestion-and-analysis layer and did not describe its administrative, device-management, agent-identity, or compliance-tooling capabilities. That description was incomplete and is superseded by this version.
• 2026-06-26. Prior version. Two-context structure, US-only scope, no-sale/no-share commitment, sovereign-AI and no-base-model-training commitments, CCPA/CPRA, Colorado CPA and AI Act, and New York SHIELD disclosures.

20. How to Contact Us.

20.1 Privacy requests and questions. Email privacy@bolde.ai for any privacy request or question, legal@bolde.ai for legal notices, and security@bolde.ai for security matters.

20.2 Mailing address. Agentic Secure Group Inc., c/o Hedberg Law, 5944 S Kipling Pkwy, Suite 200, Littleton, CO 80127.