Data Processing Addendum.

1. Introduction and Incorporation.

1.1 Parties and effect. This Data Processing Addendum (“DPA”) is entered into by and between Agentic Secure Group Inc., a Delaware C-Corporation doing business as “Bolde” (“Company,” “we,” “us”), and the customer that accepts the Terms of Service and connects data to the Service (“Customer,” “you”). This DPA is incorporated into and forms part of the Terms of Service between the parties (the “Terms”) and governs the Processing by Company, on Customer’s behalf, of Customer Data and of the additional categories identified in Section 2 in connection with the Service.

1.2 When this DPA applies. This DPA applies whenever Customer connects a business system, a workforce or HR system, or any other data source to the Service; whenever Customer grants Company administrative access to a Connected Service; whenever Customer enables Administer mode; or whenever Customer otherwise causes any category of data described in Section 2 to be Processed by Company. By connecting such data or granting such access, an authorized representative of Customer accepts this DPA on Customer’s behalf.

1.3 US-only scope. The Service is offered solely to business Customers and end users located in the United States. This DPA is built on United States federal and state privacy and data-security law and is not intended to satisfy, and does not incorporate, the EU/UK General Data Protection Regulation or any non-US data-protection regime. Customer represents that it will not use the Service to Process the personal data of individuals located in the European Union, the United Kingdom, or other jurisdictions whose law would require GDPR-style terms.

1.4 Relationship to the Terms. This DPA governs how Company Processes data. It does not authorize any Administrative Action or Destructive Action. Authorization, scope, approval, and the allocation of risk for Administrative Actions and Destructive Actions are governed by the Administer, Destructive Action, and Agent Identity provisions of the Terms, which control on those subjects. See Section 18.1.

2. Definitions.

2.1 Aligned terms. Capitalized terms not defined here have the meanings given in the Terms or the Privacy Policy. The definitions of “Customer Data,” “Control-Plane Object,” “Administrative Action,” “Destructive Action,” “Agent Identity,” “Security Signal,” “Service,” and “Subprocessor” are intended to be identical across the Terms, the Privacy Policy, and this DPA. Where a single defined term appears in more than one document, the definition in the Terms governs.

• “ASG Ecosystem” (the “ASG ecosystem”) means, collectively: Agentic Secure Group Inc., a Delaware C-Corporation, trading as Bolde, which is the contracting party under the Terms and this DPA and the operator of the Service; Agentic Secure Inc.; Mojave Research Inc., which is the verified Microsoft publisher of the applications through which the Service operates (Microsoft Partner ID 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. The ASG Ecosystem is the sole party-group term used in this DPA. Every limitation of liability, exclusion, disclaimer, indemnity, release, arbitration provision, and other protective provision in this DPA runs to, and is enforceable by, each member of the ASG Ecosystem. Obligations under this DPA are owed by Company, and no other member of the ASG Ecosystem assumes an obligation under this DPA by reason of this definition.
• “Applicable Privacy Law” means the California Consumer Privacy Act as amended by the California Privacy Rights Act and its implementing regulations (“CCPA/CPRA”), the Colorado Privacy Act and rules (“CPA”), the Colorado AI Act (SB 24-205), the New York SHIELD Act, and the comparable consumer-privacy and data-security laws of Virginia, Connecticut, Utah, Texas, Oregon, Montana, Delaware, and other US states, each as applicable to the Processing under this DPA.
• “Connected Service” means a third-party business system, identity or directory service, device-management service, workforce or HR system, or other data source that Customer connects to the Service, together with the tenant, directory, or account Customer controls within it.
• “Customer Data” means all data, content, and Personal Information that Customer or its Authorized Users connect, submit, ingest, or otherwise make available to the Service, including connected business-system content (mail, calendars, contacts, files, document and file storage, messaging and collaboration channel messages, tasks and notes, and directory, security, compliance, audit, and reporting data) and, where connected, HR/employment/organizational data from a connected workforce system, together with outputs generated by the Service from such data. Control-Plane Objects, Device and Endpoint Records, Security Signals, Agent Identity Records, and Administrative Action Records are Customer Data for purposes of Company’s confidentiality, security, purpose-limitation, retention, return, and deletion obligations under this DPA, and are separately enumerated below because they are Processed differently and carry different risk.
• “Control-Plane Object” means configuration and governance state within a Connected Service that Company can read or modify under the access Customer grants, including user, group, and directory objects and their attributes; role definitions, role assignments, and privileged-access (PIM) assignments; application registrations, service principals, application permissions, and application credentials; conditional-access, authentication-method, and other tenant security policies; domain and tenant configuration; custom security attributes; device enrollment, ownership, configuration, and compliance records; and retention, hold, eDiscovery, and subject-rights-request configuration. A Control-Plane Object is not primarily communications content, but it routinely contains Personal Information (for example, user principal names, employee identifiers, device assignment records, and attributes describing an individual), and is treated as Personal Information to that extent.
• “Device and Endpoint Record” means the subset of Control-Plane Objects describing a managed or enrolled endpoint, including device identifier, model and operating-system state, enrollment and ownership designation (including whether the Connected Service records a device as corporate-owned or personally owned), compliance and configuration status, assigned user, installed-application inventory where exposed, and, where the Connected Service exposes it, device location. Device and Endpoint Records are Control-Plane Objects; the separate term is used only where a provision applies specifically to endpoints.
• “Security Signal” means security and audit telemetry Company reads from or generates in respect of a Connected Service, including sign-in and audit log records, alerts, risk detections, policy-evaluation results, and configuration-drift findings.
• “Agent Identity” means a non-human identity provisioned in or federated to a Connected Service that the Service uses to act; “Agent Identity Record” means the directory and lifecycle record of such an identity, including its blueprint, assignments, and enablement state; and “Agent Credential” means a secret, certificate, key, or federated credential that permits authentication as an Agent Identity.
• “Administrative Action” means an operation Company performs on a Control-Plane Object under the access Customer grants, as further defined in the Terms. “Destructive Action” means an Administrative Action that deletes, disables, revokes, resets, retires, wipes, or otherwise renders unavailable an object, credential, policy, mailbox, site, account, or device, as further defined in the Terms.
• “Administrative Action Record” means the record Company generates for an Administrative Action, including the initiating human or rule, the Agent Identity used, the target list, the approval relied upon, the correlation identifier, the outcome, and the time of execution.
• “Administer Authorization” means the administrator consent and configuration by which Customer grants Company the ability to perform Administrative Actions in a Connected Service, together with the Administrative Scope Customer defines. “Designated Administrative Contact” means the individual or individuals Customer identifies to Company as authorized to grant, modify, confirm, and revoke the Administer Authorization.
• “Personal Information” (or “Personal Data”) means information that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked with a particular consumer or household, as defined under Applicable Privacy Law, that is contained within any category of data described in this Section 2.
• “Sensitive Data” means “sensitive personal information” under the CCPA/CPRA and “sensitive data” under the CPA and other Applicable Privacy Law, including Social Security numbers, government identifiers, financial account information, precise geolocation, date of birth, and similar categories, as may be contained in connected HR data, business-system content, Control-Plane Objects, or Device and Endpoint Records.
• “Process”/“Processing” means any operation performed on data covered by this DPA, including collection, ingestion, storage, use, organization, retrieval, generation of outputs, disclosure, modification, and deletion. For the avoidance of doubt, an Administrative Action, including a Destructive Action, is Processing.
• “Service” means the Bolde sovereign AI platform and its product modes (Console, Analyst, Scouts, Operator, Administer, and Auditor) and underlying models (Bolde-Small and Bolde-Custom), as described in the Terms.
• “Subprocessor” means a third party engaged by Company to Process data covered by this DPA on Company’s behalf in providing the Service. For clarity, the providers of the Connected Services Customer connects are Customer’s own service providers and data sources, not Company Subprocessors.
• “Authorized User” means an individual whom Customer permits to access or use the Service on Customer’s behalf.

2.2 Statutory roles. “Business,” “Service Provider,” “Sale,” “Share,” “Controller,” “Processor,” “Consumer,” and “Deidentified” have the meanings given under the CCPA/CPRA, the CPA, and other Applicable Privacy Law, as the context requires.

3. Roles of the Parties.

3.1 Allocation. As between the parties, Customer is the “Business” and “Controller” with respect to Customer Data, Control-Plane Objects, Device and Endpoint Records, Security Signals, Agent Identity Records, and Administrative Action Records, and Company is the “Service Provider” (under the CCPA/CPRA) and “Processor” (under the CPA and other Applicable Privacy Law) with respect to that Processing, subject to the scoping in Section 5.6. Company does not determine the purposes of the Processing.

3.2 Customer obligations as Controller. Customer is responsible for the accuracy, quality, and legality of the data it connects and for establishing the lawful basis, authority, notices, and consents necessary to connect its systems and data sources, to grant the access scopes and administrator consents it grants, to define the Administrative Scope, and to permit Company’s Processing under this DPA. Customer is responsible for configuring access scopes, defining and reviewing Operator-mode rules and Administrative Scope, designating and maintaining the Designated Administrative Contact, and supervising its Authorized Users. Customer is responsible for the notices and, where required, the individual acknowledgments it provides to its personnel regarding management actions on devices those personnel use, including personally owned devices.

3.3 Company obligations as Service Provider/Processor. Company will Process data covered by this DPA only as necessary to provide, secure, maintain, and support the Service in accordance with this DPA and Customer’s documented instructions, and not for any other purpose.

3.4 Administer mode does not change the allocation. Administer mode expands what Company can do to Control-Plane Objects; it does not expand why Company may do it, and it does not make Company a Business or Controller. Company covenants that it will not use, retain, or disclose any Control-Plane Object, Device and Endpoint Record, Security Signal, Agent Identity Record, or Administrative Action Record for Company’s own purposes, for the benefit of any other customer, for product development directed at any other customer, or for any purpose other than performing the Service for Customer and the purposes expressly permitted by the CCPA/CPRA for a Service Provider. The parties acknowledge that Administer mode confers a materially greater capability than content ingestion, and that the correctness of the Service-Provider characterization depends on Company’s adherence to this covenant and on the purpose limitation in Section 5.

4. Scope and Documented Instructions.

4.1 Documented instructions. Customer’s documented instructions to Company are set out in (a) this DPA, (b) the Terms, (c) the access scopes, administrator consents, connections, and configurations Customer enables through the Service and through the Connected Service (including which product modes, Operator rules, and Administrative Scope Customer activates), (d) the Administer Authorization, and (e) any written instructions Customer issues through the Service or to legal@bolde.ai. Company will Process data covered by this DPA only on these instructions, including with regard to transfers, unless required to do otherwise by applicable law (in which case Company will, where legally permitted, notify Customer before Processing).

4.2 The consent surfaces are the instruction instrument. Company’s access is exercised through named application registrations published by Mojave Research Inc. under Microsoft Partner ID 7086299. Each registration is separately consentable and separately declinable by Customer’s administrator. The registrations that can appear on a Customer administrator’s consent screen are:

• Bolde Ingest — M365 Content. Read-only ingestion. This registration holds exactly four application permissions, all read-only — read of mail, read of calendars, read of sites, and read of user directory objects — plus a single delegated User.Read scope. The application permissions of Bolde Ingest confer no ability to write to, modify, send from, or delete anything in a Connected Service. Bolde Ingest is the only Bolde registration whose application permissions are entirely read-only.
• Bolde Connect — User Sign-In & Data Access. User sign-in and content access. This registration carries delegated permissions exercised in the context of, and bounded by the rights of, the signed-in user, and it also carries application permissions that operate independently of any signed-in user. Its application permissions include read and write of mail, sending of mail, read and write of files and sites, read and write of chat, and read and write of calendars. Bolde Connect is not a content-only registration, and Customer should not treat it as one. Its application permissions also include governance-grade directory write — Application.ReadWrite.All, Directory.ReadWrite.All, User.ReadWrite.All, Group.ReadWrite.All, GroupMember.ReadWrite.All, and Organization.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, Customer should evaluate consent to Bolde Connect as conferring administrative authority over directory objects and as a privilege-escalation path. A substantial proportion of Bolde Connect’s application permissions are write-scoped. As to agent identities specifically, Bolde Connect holds fourteen application-only agent roles: thirteen are manager-scoped or read-scoped, and the fourteenth is AgentIdUser.ReadWrite.IdentityParentedBy, which is write authority scoped to agent identities parented to that registration rather than tenant-wide. Bolde Connect holds no tenant-wide application-only agent write authority; that statement is about Bolde Connect only and is not made about any other registration.
• Bolde Control — Tenant & Agent Governance. Privileged governance. This registration carries application permissions that include directory role management, application and service-principal management, domain configuration, conditional-access policy management, the full agent-identity lifecycle, device and endpoint management including privileged operations that can remotely wipe or retire an enrolled endpoint, Purview, eDiscovery and subject-rights-request scopes, custom security attributes, and privileged identity management. It also declares six delegated scopes: Files.ReadWrite.All, Sites.ReadWrite.All, Files.Read.All, Sites.Read.All, User.Read, and offline_access. Administrative Actions and Destructive Actions are executed through this registration.
• Bolde Keeper — Immutable Audit Anchor. Registered as a public client. It holds no Microsoft Graph application (app-only) permissions and, as registered, no client secret or certificate credential. It holds three delegated permissions — Mail.Send, email, and offline_access — meaning that, in the context of a signed-in user and bounded by that user’s own rights, it is able to send mail. It exists to anchor audit records for the Service. The absence of a credential is the operative constraint, and Customer’s administrator can verify it directly; the public-client registration flag alone does not prevent a credential being added later.

A fifth multi-tenant registration, Bolde Sentry — Security Posture & Threat Operations, is declared but holds no client secret or certificate credential and therefore cannot authenticate against any tenant. Bolde Sentry is forthcoming: it is not consented, holds no credential, and is not operational, and Company will not represent it as operational until it is consented, credentialed, and described here. It is identified now so that its future appearance on a consent screen is not a surprise. Company also maintains single-tenant application registrations used solely within Company’s own tenant for Company’s internal operations; those registrations have no access to any Customer tenant and are not part of the Service surface.

4.2A Declining a registration. Customer may consent to Bolde Ingest and Bolde Connect without consenting to Bolde Control, and thereby withhold directory-role administration, conditional-access policy authority, privileged device operations including remote wipe and retire, and tenant-wide agent lifecycle authority. Declining Bolde Control is a supported configuration and does not disable content functionality delivered through Bolde Connect or Bolde Ingest. Declining Bolde Control does not withhold all governance authority: Application.ReadWrite.All and directory-object write via Directory.ReadWrite.All are declared by Bolde Connect as well, and are conferred by consent to Bolde Connect alone. A Customer seeking a deployment with no write capability of any kind should consent to Bolde Ingest alone. Company will maintain, at bolde.ai/security, a current per-registration, permission-by-permission description, and will correct it when the permission posture of any registration changes.

4.3 Operator-mode actions. In Operator mode, the Service performs repeatable work inside the rules Customer approves, which may include reading and writing connected-system content (sending and drafting mail; creating and updating calendar events; reading and writing files and document and file storage; posting to messaging and collaboration channels). Such actions constitute Processing on Customer’s documented instruction and are confined to the scopes and rules Customer configures and may revoke.

4.4 Administer-mode actions. In Administer mode, the Service performs Administrative Actions on Control-Plane Objects, which may include creating, modifying, disabling, or deleting directory objects; assigning or removing roles and privileged assignments; creating, modifying, or removing application registrations, service principals, and application credentials; modifying conditional-access and other tenant security policies; modifying domain and tenant configuration; provisioning, enabling, disabling, restoring, or deleting Agent Identities and their credentials; and executing device-management operations up to and including remote wipe or retire of an enrolled endpoint. Each Administrative Action constitutes Processing performed on Customer’s documented instruction, and the Administer Authorization is the instruction instrument for that Processing. Company will not perform an Administrative Action outside the Administrative Scope Customer has defined. Company will generate an Administrative Action Record for every Administrative Action and will make it available to Customer.

4.5 Limits of category-level consent — forthcoming controls. As of the Last Updated date, the Administer Authorization operates at the level of permission categories and Administrative Scope. The following are forthcoming and are not in place: per-instance approval gating, meaning out-of-band confirmation by the Designated Administrative Contact against a rendered itemized target list, a mandatory pre-execution delay window with abort, and a second independent approver above a threshold number of targets; pre-action snapshot and escrow of recoverable state; and a technical restriction preventing full-device wipe of a device the Connected Service records as personally owned. Company does not have these controls today and will not represent that it does. Customer should scope the Administer Authorization accordingly and should treat Destructive Actions as, in general, not reversible by Company.

4.6 Unlawful instructions. Company will inform Customer if, in Company’s reasonable opinion, an instruction infringes Applicable Privacy Law; Company may decline or suspend Processing, including any Administrative Action, that it reasonably believes would violate applicable law or would exceed the Administrative Scope.

5. CCPA/CPRA Service-Provider Certification.

5.1 Purpose limitation. Company Processes Personal Information contained in Customer Data, Control-Plane Objects, Device and Endpoint Records, Security Signals, Agent Identity Records, and Administrative Action Records only for the limited and specified purpose of performing the Service for Customer under the Terms (the “Business Purpose”), and not for any other purpose. This purpose limitation applies in all product modes, including Administer mode.

5.2 Service-provider restrictions. Company certifies that it will not, with respect to Personal Information disclosed to or made accessible to it by or on behalf of Customer, in any product mode:

• No Sale. Sell the Personal Information (as “sell” is defined under the CCPA/CPRA).
• No Sharing. Share the Personal Information for cross-context behavioral advertising (as “share” is defined under the CCPA/CPRA).
• No retention, use, or disclosure outside the relationship. Retain, use, or disclose the Personal Information for any purpose other than the Business Purpose, including outside the direct business relationship between Company and Customer, except as expressly permitted by the CCPA/CPRA.
• No combining. Combine the Personal Information with personal information that Company receives from, or on behalf of, another person or persons, or collects from its own interaction with a consumer, except as permitted by the CCPA/CPRA and its regulations (for example, to detect security incidents, protect against fraudulent or illegal activity, or debug and repair errors that impair existing intended functionality).
• No model training on identifiable data. Use the Personal Information to build, train, or improve any generalized or foundation machine-learning model. Company does not train its Bolde-Small base model on Customer Data. Company-scoped tuning to produce a Customer’s own Bolde-Custom model occurs only with Customer’s authorization and remains scoped to that Customer.
• No cross-customer use of control-plane or security state. Use any Control-Plane Object, Device and Endpoint Record, Security Signal, Agent Identity Record, or Administrative Action Record of Customer for the benefit of any other customer, to develop or tune a benchmark, model, ruleset, or detection offered to any other customer, or to construct any cross-customer dataset that is not first de-identified or aggregated in accordance with Section 14.

5.3 Certification of understanding. Company understands the restrictions in this Section 5 and will comply with them. Company will notify Customer if it determines that it can no longer meet its obligations as a Service Provider under the CCPA/CPRA, including if a change to the Service, the Administer surface, or the Administrative Scope would place any Processing outside the scope certified in Section 5.6.

5.4 Customer rights to remediate. Customer has the right, upon notice, to take reasonable and appropriate steps to stop and remediate unauthorized use of Personal Information by Company, and to confirm that Company Processes Personal Information consistent with Customer’s obligations under Applicable Privacy Law. Customer may exercise that right unilaterally and without Company’s cooperation by revoking consent to any or all of the application registrations identified in Section 4.2 and removing the corresponding service principals from Customer’s own Connected Service tenant. Revocation of consent to Bolde Control immediately terminates Company’s ability to perform Administrative Actions.

5.5 Permitted internal uses. Consistent with the CCPA/CPRA and its regulations, Company may Process Personal Information covered by this DPA to detect security incidents; protect against malicious, deceptive, fraudulent, or illegal activity; debug and repair errors that impair existing intended functionality; comply with law and respond to lawful process; and maintain and improve the quality and safety of the Service for Customer. Company does not treat these permitted uses as a licence to build cross-customer products, and Section 5.2 constrains them.

5.6 Scope of the certification — stated precisely. The certification in Sections 5.1 through 5.3 covers all Processing Company performs on Customer’s behalf under this DPA, in every product mode including Administer mode. It does not extend to, and Company acts as a separate Business or Controller with respect to, only the following, which are Processed under the Privacy Policy rather than this DPA: (a) Company’s own account, contracting, billing, and business-contact records relating to Customer’s administrators, signatories, and billing contacts; (b) aggregate service-operations telemetry that has been de-identified or aggregated in accordance with Section 14; and (c) records Company is required to retain for its own legal, tax, audit, or dispute-defense purposes, including Administrative Action Records retained for the applicable limitations period. Company does not claim, and Customer should not assume, that any broader carve-out exists. If Company concludes that a specific Processing operation cannot be performed within Service-Provider limits, Company will not perform that operation under this DPA without first notifying Customer and obtaining a separate written instruction.

6. Details of the Processing.

6.1 Subject matter and nature. The subject matter is the provision of the Service. The nature of the Processing is (a) ingestion of Customer Data into Customer’s own sovereign Bolde deployment and the operation of the Console, Analyst, Scouts, Operator, and Auditor modes over that data; (b) reading of Control-Plane Objects, Device and Endpoint Records, and Security Signals from Connected Services; and (c) in Administer mode, execution of Administrative Actions, including Destructive Actions, on Control-Plane Objects within the Administrative Scope.

6.2 Purposes. Processing is performed to provide, secure, maintain, support, and improve the Service for Customer (improvement limited as set out in this DPA and the Terms), to perform the actions Customer authorizes in Operator mode, and to perform the Administrative Actions Customer authorizes through the Administer Authorization.

6.3 Categories of Personal Information and other Processed data.

• Connected business-system content and metadata. Mail content and headers; calendar events; contacts; files and document and file storage documents; messaging and collaboration channel and chat messages; tasks and notes; and user, group, directory, security, compliance, audit-log, and reporting data, in each case to the extent of the access Customer grants and its administrator authorizes.
• Connected HR data (optional). Employment, organizational, and HR records, which may include Sensitive Data such as Social Security numbers, dates of birth, and home addresses (for example, via the personal_information scope).
• Control-Plane Objects. User, group, and directory objects and attributes; role definitions, role assignments, and privileged-access assignments; application registrations, service principals, application permissions, and application credential metadata; conditional-access, authentication-method, and other tenant security policies; domain and tenant configuration; custom security attributes; and retention, hold, eDiscovery, and subject-rights-request configuration.
• Device and Endpoint Records. Device identifiers, hardware and operating-system state, enrollment and ownership designation (including corporate-owned versus personally owned as recorded by the Connected Service), assigned user, configuration and compliance status, installed-application inventory where exposed, and, where the Connected Service exposes it, device location, which may constitute precise geolocation and is treated as Sensitive Data.
• Security Signals. Sign-in and audit log records; alerts, risk detections, and identity-risk findings; policy-evaluation results; and configuration-drift findings. Security Signals routinely identify individual users and devices and are treated as Personal Information to that extent.
• Agent Identity Records and Agent Credentials. Agent identity objects, blueprints, assignments, enablement and lifecycle state, and the credentials that permit authentication as an Agent Identity. Agent Credentials are treated as Customer secrets and are subject to Section 8.4.
• Administrative Action Records. The initiating human or rule, the Agent Identity used, the approval relied upon, the itemized target list, the correlation identifier, the outcome, and the execution time for each Administrative Action, including each Destructive Action.
• Account and usage data. Authorized User identifiers, configuration settings, Operator rules, Administrative Scope definitions, and Service logs.

6.4 Categories of data subjects. Customer’s personnel, employees, contractors, and Authorized Users; Customer’s correspondents and counterparties whose information appears in connected business-system content; individuals whose devices — whether corporate-owned or personally owned — are enrolled in or managed through a Connected Service; individuals identified in Control-Plane Objects, Security Signals, or Administrative Action Records; and other individuals whose Personal Information Customer chooses to connect.

6.5 Frequency and duration. Ingestion and reading occur continuously or on a schedule Customer configures. Administrative Actions occur on Customer instruction or under Customer-approved rules. Processing continues for the term of the Terms and until deletion or return as set out in Section 16, except that Administrative Action Records are retained as provided in Section 16.5.

7. Confidentiality of Personnel.

7.1 Commitment. Company ensures that personnel authorized to Process data covered by this DPA are bound by appropriate written confidentiality obligations (contractual or statutory) and have received appropriate training regarding their responsibilities.

7.2 Least privilege. Company limits access to data covered by this DPA to those personnel who require access to provide the Service, on a need-to-know, least-privilege basis, with access to Sensitive Data fields, to Agent Credentials, and to the ability to initiate Administrative Actions subject to additional restriction and monitoring.

8. Security Measures.

8.1 Security program. Company maintains a written information-security program with administrative, technical, and physical safeguards aligned to recognized frameworks (such as ISO 27001 and the NIST family of controls) and designed to meet the requirements of the New York SHIELD Act and other Applicable Privacy Law, appropriate to the nature of the data Processed, including Sensitive Data, Control-Plane Objects, and Agent Credentials.

8.2 Technical and organizational measures. Company maintains, and will continue to maintain throughout the term, at least the following:

• Encryption. Encryption of data covered by this DPA in transit and at rest using industry-standard algorithms.
• Access control. Role-based access control, least-privilege provisioning, strong authentication, and separation of production and non-production environments.
• Separation of privilege across application registrations. Read-only ingestion is performed through Bolde Ingest, a registration whose application permissions are read-only. Privileged governance capability — directory-role administration, conditional-access policy authority, privileged device operations including remote wipe and retire, and tenant-wide agent lifecycle authority — is isolated in Bolde Control, which Customer may decline. For the avoidance of doubt, and as stated in Section 4.2A, declining Bolde Control does not withhold every write capability: Bolde Connect independently carries governance-grade directory write permissions. Company does not represent that a tenant which has not consented to Bolde Control has granted no privileged capability.
• Sovereign hosting. Processing and inference on Company-controlled, sovereign infrastructure located in the United States. Company does not route Customer Data through any third-party large-language-model vendor, and no such vendor is in the inference data path for the Bolde-Small or Bolde-Custom models.
• Logging and monitoring. Audit logging (including the Auditor record and the Keeper anchor), monitoring, and testing of safeguards, with heightened logging for access to Sensitive Data, for use of Agent Credentials, and for every Administrative Action.
• Resilience and recovery. Backup, business-continuity, and incident-response procedures for Company’s own systems. These protect Company’s systems; they do not restore data destroyed inside a Connected Service by a Destructive Action.
• Risk management. Periodic risk assessments, vulnerability management, and personnel security training.

8.3 Privilege ceiling for Administer mode. Company will not hold, request, or activate the Global Administrator, Privileged Role Administrator, or Application Administrator role (or an equivalent tenant-wide superuser role in a Connected Service) except pursuant to an express, per-instance written authorization from the Designated Administrative Contact, and will relinquish it immediately upon completion of the authorized work. Company operates Administer mode through scoped application permissions rather than standing superuser roles. This is a binding covenant of Company and is not a description of a technical control.

8.4 Agent Credential handling. Company stores Agent Credentials and application credentials in a dedicated secrets store with restricted access, does not write them to logs or support tooling, and rotates them on a defined schedule and upon any suspected exposure. Customer may revoke any credential unilaterally from its own tenant at any time without Company’s cooperation. Provisioning of Agent Credentials that are generated in, and held non-exportably by, Customer’s own tenant, with Company holding only a Customer-revocable federated credential, is forthcoming and is not in place as of the Last Updated date.

8.5 Forthcoming controls — stated so they are not assumed. The following are forthcoming and are not in place as of the Last Updated date: (a) per-instance approval gating, as distinct from the per-category consent and Administrative Scope that operate today, including an itemized target list, a mandatory pre-execution delay window with abort, and a second independent approver above a threshold; (b) pre-action snapshot or escrow of recoverable state before a Destructive Action; (c) a technical restriction preventing full-device wipe of a device that a Connected Service records as personally owned, including a device personally owned by an individual associated with Customer; (d) individually assented end-user device terms captured as a per-individual artifact; and (e) Bolde Sentry, which holds no credential, is not consented, and is not operational. Company will not describe any of these as in place until it is, and Company will update this Section when the status of any of them changes. Nothing elsewhere in this DPA, the Terms, the Privacy Policy, or the security page should be read as asserting that any control in this Section exists today.

8.6 Updates. Company may update its security measures from time to time provided that such updates do not materially diminish the overall security of the Service.

9. Subprocessors.

9.1 General authorization. Customer provides general written authorization for Company to engage Subprocessors to Process data covered by this DPA in providing the Service, subject to this Section 9.

9.2 Current Subprocessors. Company’s Subprocessors are limited to providers of Company-controlled sovereign compute and hosting infrastructure used to operate the Service within the United States. Company maintains a current list of Subprocessor categories and identities, available on request to legal@bolde.ai.

9.3 Customer’s own providers are not Subprocessors. The providers of the Connected Services — including the identity, collaboration, and device-management platforms in respect of which Customer grants administrator consent — are Customer’s own service providers and data sources. They are not Company Subprocessors, and Company is not responsible for their acts or omissions in their capacity as Customer’s providers. Nothing in this Section limits Company’s responsibility for its own acts within a Connected Service.

9.4 Notice and right to object. Company will provide Customer advance notice (by email or through the Service) before adding or replacing a Subprocessor. Customer may object on reasonable, good-faith data-protection grounds within fifteen (15) days of notice. If the parties cannot resolve the objection, Customer may, as its sole remedy, terminate the affected portion of the Service and receive a pro-rata refund of prepaid, unused fees.

9.5 No Subprocessor executes Administrative Actions. Company does not permit any Subprocessor to initiate or execute an Administrative Action or to hold an Agent Credential. Company will give Customer at least thirty (30) days’ advance written notice before changing this position, and Customer may terminate Administer mode without penalty during that period.

9.6 Flow-down and liability. Company imposes on each Subprocessor, by written contract, data-protection, confidentiality, security, breach-notification, and deletion/return obligations no less protective than those in this DPA. Company remains fully responsible and liable to Customer for the performance of each Subprocessor’s obligations and for any acts or omissions of a Subprocessor that cause Company to breach this DPA.

10. Assistance to Customer.

10.1 Data-subject and consumer requests. Taking into account the nature of the Processing, Company provides reasonable assistance, through appropriate technical and organizational measures, to enable Customer to respond to verifiable consumer requests to know, access, correct, delete, opt out of Sale/Sharing, or limit the use of Sensitive Data under Applicable Privacy Law. That assistance extends to Personal Information contained in Control-Plane Objects, Device and Endpoint Records, Security Signals, and Administrative Action Records, subject to Section 16.5. If Company receives such a request directly from a data subject, Company will, unless legally prohibited, promptly route the request to Customer and not respond except on Customer’s instruction or as required by law.

10.2 Requests concerning device actions. If an individual contacts Company concerning a management action taken on a device that individual uses, Company will route the request to Customer and will, on Customer’s instruction, provide Customer the relevant Administrative Action Record so that Customer may respond. Company does not adjudicate such requests and does not represent that the individual’s claim is answered by the existence of Customer’s authorization.

10.3 Risk and impact assessments. Company provides Customer, on reasonable request, information reasonably necessary to support Customer’s data-protection assessments, CCPA/CPRA risk assessments, CPA assessments, and any high-risk-AI impact assessments under the Colorado AI Act (SB 24-205), including descriptions of the Processing, the security measures, the permission inventory of each consented application registration, the Subprocessor list, and applicable retention periods.

10.4 Automated decisionmaking. The Service is designed for human-in-the-loop operation (Console review and approval; Operator actions confined to Customer-approved rules; Administrative Actions confined to the Administrative Scope). Where Customer uses the Service in a manner that constitutes automated decisionmaking technology (ADMT) or high-risk AI under Applicable Privacy Law, Customer is responsible for providing required consumer notices, logic explanations, and opt-out or appeal mechanisms, and Company will provide reasonable supporting information about the Service’s general logic, the categories of Personal Information used, and the types of outputs and actions the Service supports. Customer acknowledges that an Administrative Action executed under a rule, without contemporaneous human review of the individual target, may constitute automated decisionmaking with respect to the affected individual.

11. Security Incidents and Destructive-Action Incidents.

11.1 Notice without undue delay. Company will notify Customer without undue delay consistent with applicable law, after Company becomes aware of a confirmed breach of security leading to the accidental or unlawful destruction, loss, alteration, or unauthorized disclosure of or access to data covered by this DPA and Processed by Company (a “Security Incident”).

11.2 Contents and cooperation. The notice will describe, to the extent known, the nature of the Security Incident, the categories and approximate number of data subjects and records affected, the likely consequences, and the measures taken or proposed to address it. Company will provide reasonable cooperation and information to enable Customer to meet its breach-notification obligations.

11.3 Statutory timelines. The parties acknowledge that Customer, as Controller/Business, is responsible for any required notifications to consumers and regulators. Company’s notice under Section 11.1 is intended to allow Customer to satisfy applicable deadlines, including: California (notice to affected residents in the most expedient time possible and without unreasonable delay, per Cal. Civ. Code § 1798.82); Colorado (notice to affected residents in the most expedient time possible and without unreasonable delay, and in any event not later than thirty (30) days after determination that a breach occurred, and, where 500 or more Colorado residents are affected, notice to the Colorado Attorney General, per C.R.S. § 6-1-716); and New York (notice in the most expedient time possible and without unreasonable delay under the SHIELD Act, N.Y. Gen. Bus. Law § 899-aa), as well as the comparable laws of other US states.

11.4 When a Destructive Action is a Security Incident — stated expressly. A Destructive Action that Company executes within the Administrative Scope and in accordance with a valid Administer Authorization is authorized Processing and is not a Security Incident, even though it destroys or renders unavailable data or access. A Destructive Action is a Security Incident, and Sections 11.1 through 11.3 apply in full, if it (a) is executed outside the Administrative Scope; (b) is executed without a valid authorization, or under an authorization that has been revoked, expired, or exceeded; (c) strikes a target other than the target identified in the authorization, including as a result of misidentification, a defective rule, or an error in target resolution; (d) destroys or renders unavailable data or access that the authorization did not encompass; or (e) is executed against an asset that Company knew, or from information available to Company reasonably should have determined, was subject to a litigation hold, preservation obligation, or equivalent restriction. The parties intend this Section to be read against the definition in Section 11.1: unauthorized or mistargeted destruction is exactly the “accidental or unlawful destruction” that definition covers, and Company does not contend otherwise.

11.5 Destructive Action Incident notice — 24 hours. Independent of whether an event is a Security Incident under Section 11.4, Company will notify the Designated Administrative Contact within twenty-four (24) hours after Company becomes aware that a Destructive Action has been executed and that any of the conditions in Section 11.4(a) through (e) may apply. The notice will include, to the extent known: the itemized list of targets affected; the Administrative Action Record, including the initiating human or rule, the Agent Identity used, the approval relied upon, and the correlation identifier; Company’s then-current assessment of what was destroyed or rendered unavailable; and the restoration options actually available. Because pre-action snapshot and escrow is forthcoming and is not in place (Section 8.5), the restoration options available in most cases are limited to those the Connected Service’s own native recovery mechanisms and Customer’s own backup arrangements provide. Company does not represent that any Destructive Action is reversible.

11.6 Preservation and cooperation. Following any notice under Section 11.4 or 11.5, Company will preserve the relevant Administrative Action Records, approval records, Keeper anchor records, and associated logs, will not alter or delete them except as required by law, and will make them available to Customer on request, including for use in Customer’s own legal or regulatory proceedings.

12. Audits.

12.1 Audit information. Company makes available to Customer information reasonably necessary to demonstrate compliance with this DPA, including, on request and where available, summary reports, third-party attestations (such as SOC 2 Type II or ISO 27001 audit reports), the permission inventory of each consented application registration, and responses to a reasonable security questionnaire.

12.2 Administrative Action records available on demand. Company will make Administrative Action Records, including approval records and Keeper anchor references, available to Customer on request at any time during the term and for the retention period in Section 16.5, without limitation by the frequency cap in Section 12.3. Customer may verify any individual Administrative Action against those records.

12.3 On-site audits. Where Applicable Privacy Law grants Customer a right to audit that cannot be satisfied by Sections 12.1 and 12.2, Customer may, no more than once per twelve (12) months (except where required by a regulator, following a confirmed Security Incident, or following a notice under Section 11.5), conduct an audit limited to the systems relevant to the Processing, upon at least thirty (30) days’ written notice, during business hours, subject to confidentiality obligations, and in a manner that does not disrupt Company’s operations or compromise the security or sovereignty of other customers’ data. Customer bears its own audit costs.

12.4 Confidentiality of results. All audit information and results are the Confidential Information of the ASG Ecosystem and may be used only to verify compliance with this DPA, to respond to a regulator, or in a proceeding between the parties.

13. Sensitive Data Handling.

13.1 Heightened controls. Where Customer connects Sensitive Data (including connected HR data containing Social Security numbers, dates of birth, or home addresses; business-system content containing such elements; Control-Plane Objects such as custom security attributes that Customer populates with sensitive values; or Device and Endpoint Records containing precise geolocation), Company applies heightened safeguards, including restricted role-based access to Sensitive Data fields, separate access logging, and, where feasible, minimization or pseudonymization for analytics. Any de-identified or aggregated data so produced is subject to the De-Identification Undertaking in Section 14.

13.2 Device location. Where a Connected Service exposes device location to Company’s device-management access, Company treats it as precise geolocation and therefore as Sensitive Data. Company retrieves device location only where necessary to perform an action Customer has authorized, does not retain it beyond the associated Administrative Action Record, and does not use it to infer characteristics about an individual.

13.3 Customer authorization and limitation. Customer authorizes the connection of Sensitive Data and represents that it has the authority and any consents necessary to do so, including with respect to Sensitive Data appearing in Control-Plane Objects and Device and Endpoint Records. Company Processes Sensitive Data only as needed to provide the Service and not to infer characteristics about a consumer outside the Business Purpose.

13.4 Biometrics — precise statement. The Service does not capture, store, or use biometric identifiers or biometric information as defined by the Illinois Biometric Information Privacy Act (BIPA) or comparable laws. Company’s access to a Connected Service may return configuration metadata indicating whether a user has enrolled a biometric authentication method (for example, whether a platform authenticator is registered on a device). Such metadata is a statement about the configuration of an authentication method and is not a biometric identifier or biometric information; it contains no biometric template, scan, or measurement, and Company does not attempt to derive one. Customer must not use the Service to Process biometric identifiers or biometric information, and Customer must not populate any Control-Plane Object field with a biometric template or scan.

14. CPRA De-Identification Undertaking.

14.1 Scope. This undertaking applies to any de-identified or aggregated data that Company derives from any category of data covered by this DPA (including data minimized or pseudonymized for analytics under Section 13.1). “Deidentified” has the meaning given under the CCPA/CPRA, and such data, when properly de-identified, is not Personal Information.

14.2 Company commitments. With respect to such de-identified or aggregated data, Company, consistent with the CCPA/CPRA, will: (a) take reasonable measures to ensure the information cannot be associated with a consumer or household, and not attempt to reidentify the information; (b) maintain and use the information only in a de-identified or aggregated form, and publicly commit to do so; (c) maintain technical and organizational safeguards designed to prohibit reidentification; and (d) contractually obligate any recipient of the information to comply with the same restrictions, including the prohibition on reidentification.

14.3 Control-plane and security state. De-identification does not license cross-customer use that Section 5.2 prohibits. Company will not derive from a Customer’s Control-Plane Objects or Security Signals any dataset, benchmark, or detection ruleset offered to another customer unless the derived data is aggregated across a sufficient number of customers that it cannot reasonably be associated with Customer, and Customer’s tenant is not identifiable within it.

15. United States Data Residency; No International Transfers.

15.1 US-only Processing. Company Processes and stores data covered by this DPA on Company-controlled infrastructure located in the United States. Company does not transfer such data outside the United States in providing the Service. Because the Service is offered only to US Customers and end users, no cross-border transfer mechanism (such as Standard Contractual Clauses) applies. Customer acknowledges that the Connected Services Customer chooses may store or replicate Customer’s data in locations Customer configures with those providers, which is outside Company’s control and is not a Company transfer.

16. Return, Deletion, and Deprovisioning on Termination.

16.1 Return or deletion. Upon expiration or termination of the Terms, or earlier upon Customer’s written request, Company will, at Customer’s election, return data covered by this DPA in a commercially reasonable format and/or delete it from its systems, except where retention is required by applicable law or permitted by Section 16.5.

16.2 Timing and residual copies. Company will complete deletion within thirty (30) days of the request or termination, subject to deletion from routine backups in the ordinary course. Pending deletion, Company will continue to protect the data in accordance with this DPA. On request, Company will provide written confirmation of deletion.

16.3 Customer-revocable access. Customer may at any time revoke the Service’s access, and the Administer Authorization, through its Connected Service administrator. Revocation is effected in Customer’s own tenant, takes effect immediately, does not require Company’s cooperation or consent, and halts further ingestion and any further Administrative Action.

16.4 Agent Identity and credential deprovisioning. Upon expiration or termination of the Terms, upon suspension of the Service, or upon Customer’s written request, Company will (a) cease all use of every Agent Identity and Agent Credential associated with Customer, (b) revoke and destroy every Agent Credential in Company’s possession or control within seventy-two (72) hours, and (c) provide Customer, on request, a written attestation identifying each Agent Identity and Agent Credential and confirming its revocation and destruction and the date thereof. Company will cooperate with Customer’s deletion of Agent Identity Records from Customer’s own directory. Nothing in this Section limits Customer’s ability to revoke or delete any Agent Identity or credential unilaterally at any time under Section 16.3. This Section 16.4 survives termination.

16.5 Retention of Administrative Action Records. Notwithstanding Sections 16.1 and 16.2, Company retains Administrative Action Records, approval records, and associated Keeper anchor references for the longer of (a) four (4) years or (b) the applicable statute of limitations for a claim arising from the recorded action, for the purposes of audit, dispute resolution, and legal defense, and will Process them only for those purposes and for no other. Customer may request a copy of its Administrative Action Records at any time during that period. Company will delete them at the end of the retention period absent a legal-hold obligation.

17. Liability.

17.1 Tie to the Terms; who is protected. Each party’s liability arising out of or related to this DPA, whether in contract, tort, or otherwise, is subject to the limitations of liability and exclusions of damages set out in the Terms, including any separate limitation or sub-cap the Terms apply to claims arising from a Destructive Action, and any reference in the Terms to the liability of a party means the aggregate liability of that party under the Terms and this DPA combined. Those limitations, exclusions, and disclaimers, and the release and dispute-resolution provisions referenced in Section 18.2, run to and are enforceable by each member of the ASG Ecosystem as defined in Section 2, and Customer’s aggregate recovery against all members of the ASG Ecosystem combined is subject to a single cap and is not multiplied by the number of entities named. Nothing in this DPA increases or removes the liability provisions set out in the Terms.

17.2 Carve-outs. The limitations referenced in Section 17.1 do not apply to: (a) a party’s fraud, willful misconduct, or gross negligence; (b) any liability that cannot be limited or excluded under applicable law, including under Applicable Privacy Law; and (c) any claim arising from an intentional tort, including conversion or trespass to chattels, to the extent Cal. Civ. Code § 1668 or a comparable law of another state applies.

17.3 Third persons. This DPA allocates responsibility solely as between Company and Customer. It confers no rights on, and imposes no obligation upon, any employee, contractor, device owner, correspondent, or other individual who is not a party, and it does not limit any right such a person may have against Customer or against any member of the ASG Ecosystem under applicable law. The extension of the protective provisions to the ASG Ecosystem under Section 17.1 operates only as against Customer and confers no benefit as against any non-party.

17.4 Company indemnity for evidence-preservation sanctions. Company will defend and indemnify Customer against monetary sanctions imposed on Customer by a court or regulator for loss of evidence, to the extent the loss was caused by a Destructive Action Company executed against an asset that Company knew, or from information available to Company through its consented access reasonably should have determined, was subject to a litigation hold, preservation obligation, or equivalent restriction. This indemnity does not extend to any loss to the extent caused by Customer’s own failure to place, record, or maintain a hold in the Connected Service, or by Customer’s instruction to proceed notwithstanding a known hold.

18. Order of Precedence; General.

18.1 Precedence. In the event of a conflict between this DPA and the Terms regarding how data covered by this DPA is Processed, protected, retained, returned, or deleted, this DPA controls. In the event of a conflict between this DPA and the Terms regarding the authorization, scope, approval, execution, or allocation of risk of an Administrative Action, a Destructive Action, or an Agent Identity, the Administer, Destructive Action, and Agent Identity provisions of the Terms control. In the event of a conflict between this DPA and the Privacy Policy regarding business Customer Data, this DPA controls. The CCPA/CPRA service-provider terms in Section 5 control over any conflicting provision of this DPA with respect to Personal Information governed by the CCPA/CPRA. Where any document in this package describes a control as in place and Section 8.5 of this DPA describes that control as forthcoming, Section 8.5 controls.

18.2 Governing law and venue. This DPA is governed by the laws of the State of Delaware, without regard to conflict-of-laws principles, and the dispute-resolution, arbitration, class-waiver, and venue provisions of the Terms (including the carve-out venue of the state courts of Arapahoe County, Colorado or the U.S. District Court for the District of Colorado) apply to disputes arising under this DPA and are enforceable by each member of the ASG Ecosystem, subject to any right to bring a claim in court that applicable law makes non-waivable and to any relief that applicable law makes non-waivable in any forum.

18.3 Changes. Company may update this DPA from time to time consistent with the change-management provisions of the Terms; material changes will be communicated by conspicuous notice, and continued use of the Service after the effective date constitutes acceptance. A change that expands the categories of data Processed, expands the Administrative Scope available to Company, or narrows the scope of the certification in Section 5.6 will be communicated by direct written notice to the Designated Administrative Contact at least thirty (30) days before it takes effect, and Customer may terminate the affected portion of the Service without penalty during that period.

18.4 Survival. Sections 5, 7, 8, 11, 14, 15, 16, 17, and 18 survive termination of this DPA to the extent necessary to give them effect.

18.5 Notices. Legal notices under this DPA are sent to legal@bolde.ai or to Agentic Secure Group Inc., c/o Hedberg Law, 5944 S Kipling Pkwy, Suite 200, Littleton, CO 80127. Privacy requests may be directed to privacy@bolde.ai. Security and Destructive Action Incident notices are sent to and from security@bolde.ai.

18.6 Last updated. This DPA was last updated on July 25, 2026, and is in effect as of that date.