Security.

1. Security Overview.

This page describes how Agentic Secure Group Inc., a Delaware C-Corporation doing business as Bolde (“Company,” “we,” “us,” or “our”), approaches the security of the Bolde service (the “Service”) and of bolde.ai (the “Site”). It is written to be accurate and independently verifiable by a customer administrator against Microsoft's own records. Where a control does not exist, we say that it does not exist and describe it as forthcoming. Section 11 consolidates every forthcoming control in one list.

Our security property is not narrowness of permission. It is separation, disclosure, and customer control. Bolde performs work inside a customer's Microsoft 365 environment—including administrative work—and the permissions required to do that work are broad. We do not characterize that surface as minimal. Instead we split it across distinct enterprise applications so that a customer can decline governance authority and still receive content functionality, we disclose every category of permission against the application ID that carries it, and we leave revocation entirely in the customer's hands.

1.1 The ASG ecosystem. Where this page refers to the ASG ecosystem, it means, collectively:

• Agentic Secure Group Inc., a Delaware C-Corporation trading as Bolde — the contracting party and the operator of the Service;
• Agentic Secure Inc.;
• Mojave Research Inc. — the Microsoft-verified publisher of the applications described in Section 3, under Microsoft Partner ID 7086299;
• IP Strategy & Advocacy;
• Agent Xero LLC; and
• Agentic Trace LLC;
• together with their respective parents, subsidiaries, affiliates, predecessors, successors and assigns, and their respective officers, directors, employees, agents, contractors and licensors.

Every disclaimer, limitation, allocation of responsibility, release and grant of authorization on this page runs to and for the benefit of the ASG ecosystem, and not to Agentic Secure Group Inc. alone. Mojave Research Inc. is the publisher of record for every application registration listed in Section 3; a statement on this page about application behavior is a statement about applications published by Mojave Research Inc. and operated by Agentic Secure Group Inc.

1.2 How to read this page. This page contains three kinds of statement, and they carry different weight. Please do not read one as another:

• Capability disclosure. Statements of present fact about what a named application registration is technically permitted to do. These are verifiable against Microsoft's consent screen and the Microsoft Entra admin center. Section 3.7 tells you how to check them.
• Binding commitments. Obligations we undertake, marked as such. These are commitments a customer may hold us to, and they are incorporated by reference into our Terms of Service and our Data Processing Addendum. Where a commitment is a covenant about our conduct rather than a technical impossibility, we say so, because the distinction matters to your risk assessment.
• Forthcoming controls. Controls that do not exist today. They are described so that you know they are absent, not so that you can rely on them. Nothing marked forthcoming is a commitment as to scope or date, and nothing marked forthcoming may be relied on in a consent, purchasing, or risk-acceptance decision.

1.3 No security measure is absolute. No system, organization, or set of controls can guarantee perfect security, and nothing on this page is a warranty, guarantee, or representation by any member of the ASG ecosystem that the Service or the Site is invulnerable or that any control will prevent every unauthorized act. Except as to the binding commitments identified on this page, this page is provided for information only; the security obligations that legally bind us in a given engagement are those set out in the agreement between the customer and the Company, and this page is qualified by the disclaimers and limitations in our Terms of Service and our Data Processing Addendum. How we handle personal information is described in our Privacy Policy.

2. Architecture: Separation of Duties.

Bolde does not ship as one enterprise application holding every permission it might ever need. Capability is split across separate Microsoft Entra ID application registrations, each of which a customer consents to—or declines—independently, and each of which a customer can delete from its tenant independently.

• Bolde Connect — User Sign-In & Data Access. User authentication, the productivity data plane (mail, chat, files, sites, calendar), and directory-object and application-registration write. This registration is not content-only; see Section 3.1.
• Bolde Control — Tenant & Agent Governance. The privileged plane: directory role administration, Conditional Access policy, domain modification, Entra Agent ID lifecycle, Microsoft Intune device management, Microsoft Purview and eDiscovery, Privileged Identity Management. Separate consent, separate revocation.
• Bolde Ingest — M365 Content. A deliberately tiny content ingestion identity, and the only Bolde application whose application permissions are entirely read-only.
• Bolde Keeper — Audit Anchor. Registered as a public client with no client secret, no certificate credential and no application permissions. It does hold three delegated permissions, one of which is Mail.Send; see Section 3.4.
• Bolde Sentry — Security Posture & Threat Operations. Declared but not consented, not credentialed, and not operational. Forthcoming. See Sections 3.5 and 11.

A customer may consent to Bolde Ingest and Bolde Connect without consenting to Bolde Control, and thereby withhold directory-role administration, Conditional Access policy authority, domain modification, Intune privileged device operations and tenant-wide agent lifecycle authority. This does not withhold all governance authority. Bolde Connect itself declares Application.ReadWrite.All, Directory.ReadWrite.All, User.ReadWrite.All, Group.ReadWrite.All, GroupMember.ReadWrite.All and Organization.ReadWrite.All. A customer seeking a genuinely read-only deployment should consent to Bolde Ingest alone, which is the only Bolde application whose application permissions are entirely read-only.

2.1 Why the surface is broad, and what separation does and does not achieve. We do not describe Bolde's permission set as “least privilege” in the conventional sense, because it would be misleading to do so. An agent platform that administers a Microsoft 365 tenant needs the permissions an administrator has. What separation achieves here is real but bounded: the highest-consequence permissions—device wipe and retire, directory role assignment, Conditional Access policy modification, domain modification and tenant-wide agent lifecycle authority—are confined to Bolde Control, which is separately consentable and separately revocable, and declining it is a real and supported deployment mode. Separation does not confine directory-object write or application-registration write to Bolde Control. Those permissions are also declared by the sign-in application, and we state that here rather than let the architecture claim carry more weight than it can bear.

3. Application-by-Application Permission Disclosure.

The following is the deployed customer-facing application surface. Every application listed in Sections 3.1 through 3.5 is a multi-tenant enterprise application that appears on a Microsoft administrator consent screen and is published under Microsoft-verified publisher Mojave Research Inc., Microsoft Partner ID 7086299. Application IDs are given so that an administrator can reconcile this page against what Microsoft actually shows. Counts are derived programmatically from each registration's declared permission manifest, not transcribed; Section 3.7 states the queries.

A note on the counts. The category counts below are overlapping subsets of a registration's permission set and are not a partition; they are not expected to sum to the registration total. What a customer tenant grants on consent is bounded by the registration's declared manifest as presented on the Microsoft consent screen.

3.1 Bolde Connect — User Sign-In & Data Access. Application ID 98b0f1c8-eaf1-4f43-9255-1ace882e270e. Declares 307 application (app-only) permissions and 93 delegated permissions. Its permission set includes, and is not limited to:

• Directory and identity write. Application.ReadWrite.All, Directory.ReadWrite.All, User.ReadWrite.All, Group.ReadWrite.All, GroupMember.ReadWrite.All and Organization.ReadWrite.All. These are governance-grade permissions and they are in the sign-in application, not only in Bolde Control. 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 treat consent to Bolde Connect as conferring administrative authority over directory objects, and should evaluate it as a privilege-escalation path. Of Bolde Connect's 307 application permissions, 80 end in .ReadWrite.All. Bolde Connect is not a content-only application and this page does not describe it as one.
• Mailbox. Mail.Read, Mail.ReadWrite and Mail.Send. Bolde Connect can read, modify and send mail.
• Teams chat. Chat.Read.All and Chat.ReadWrite.All. This reaches private, group and meeting chat, not only channel messages.
• Files and sites. Files.ReadWrite.All and Sites.ReadWrite.All.
• Calendar. Calendars.ReadWrite.
• Entra Agent ID — delegated. 33 delegated Entra Agent ID scopes, enabling agentic actions in the context of a signed-in user. A delegated scope is bounded by the effective rights of that signed-in user: the agent cannot exceed what the person operating it could do themselves, and Microsoft enforces that boundary, not Bolde.
• Entra Agent ID — application-only, constrained. 14 app-only agent roles. Thirteen are manager-scoped or read-scoped (the .ManagedBy, CreateAsManager and .Read.All variants); the fourteenth is AgentIdUser.ReadWrite.IdentityParentedBy, which is write authority scoped to agent identities parented to this application rather than tenant-wide. This application holds no tenant-wide app-only agent write authority. That statement is about the application with application ID 98b0f1c8-eaf1-4f43-9255-1ace882e270e only; tenant-wide agent lifecycle authority lives in Bolde Control, disclosed at Section 3.2.

3.2 Bolde Control — Tenant & Agent Governance. Application ID ba2d80a5-2b27-470f-905e-827f2630af75. Declares 236 application (app-only) permissions, of which 234 are grantable and consented. This is the privileged application. Its permission set includes:

• Directory and identity administration. RoleManagement.ReadWrite.Directory (assign and remove directory roles), Application.ReadWrite.All (create and modify application registrations and their credentials) and Domain.ReadWrite.All (modify tenant domains).
• Conditional Access. Policy.ReadWrite.ConditionalAccess (create and modify Conditional Access policies).
• Entra Agent ID lifecycle. 34 roles covering the full agent identity lifecycle, including AgentIdentity.Create.All, AgentIdentity.EnableDisable, AgentIdentity.DeleteRestore and AgentIdentityBlueprint.AddRemoveCreds.All.
• Microsoft Intune and device management. 18 roles, including DeviceManagementManagedDevices.PrivilegedOperations.All, which permits remote wipe and retire of managed endpoints. See Section 4.
• Microsoft Purview, eDiscovery and Subject Rights Requests. 26 roles. Among other things, this means Bolde is technically capable of querying a tenant's native legal hold and preservation state. Honoring that state as an automatic, non-overridable block on destructive operations does not exist today and is forthcoming; see Section 11.
• Attribute-based access control. 7 roles covering custom security attributes.
• Privileged Identity Management. 38 roles.
• Delegated permissions. In addition to its application permissions, Bolde Control declares six delegated scopes: Files.ReadWrite.All, Sites.ReadWrite.All, Files.Read.All, Sites.Read.All, User.Read and offline_access. Two of these confer content write in the context of a signed-in user, and we disclose them rather than describe this registration in app-only terms alone.
• Declared but not grantable. AgentCard.Read.All and AgentCard.ReadWrite.All are declared on this registration but are disabled by Microsoft in preview and are not consented and not usable. They account for the difference between 236 declared and 234 consented.

3.3 Bolde Ingest — M365 Content. Application ID eb9a1494-2237-4722-99c8-d305a652dabf. This application, and this application alone, holds exactly four application permissions, all read-only, plus a single delegated User.Read scope. The four application permissions are:

• Mail.Read
• Calendars.Read
• Sites.Read.All
• User.Read.All

Bolde Ingest holds no write, send, delete, directory, policy, agent-lifecycle or device permissions. This statement describes the application with application ID eb9a1494-2237-4722-99c8-d305a652dabf only. It is not a statement about Bolde Connect, Bolde Control, or the Service as a whole.

3.4 Bolde Keeper — Audit Anchor. Application ID 117a680a-0085-4666-9219-61abe9139797. Registered as a public client. It holds no client secret and no certificate credential, and no Microsoft Graph application (app-only) permissions. It does hold 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. We disclose that expressly, because an undisclosed send capability inside a component described as an audit anchor would be materially misleading. It exists to anchor audit records for the Service.

As registered today, Bolde Keeper has no credential of any kind and therefore cannot currently authenticate as an application identity against a customer tenant. We note for completeness that the public-client flag alone is not a durable technical guarantee: it does not prevent a credential being added later, and elsewhere in our own estate a registration carrying that flag does hold a secret. The guarantee here is the absence of a credential, and we commit to disclose it on this page, with a dated entry under Section 16, before provisioning any credential for this registration.

3.5 Bolde Sentry — Security Posture & Threat Operations. Forthcoming; not operational. Application ID 3595ec54-f02e-4a89-9e72-7ab5fa33f04b. This registration declares 103 application permissions spanning threat intelligence, hunting, indicators, assessment and submission; Microsoft Defender for Identity; identity risk including IdentityRiskyAgent; Microsoft Entra Internet Access and Private Access network policy; SPIFFE workload identity; mTLS OAuth; the unified AuditLogsQuery-* family; configuration monitoring; and EntraBackup. As of the “Last updated” date above, Bolde Sentry has no client secret and no certificate credential provisioned and holds no consented application role assignments. It is not operational and performs no function. Without a credential it cannot complete the client-credentials flow and so cannot authenticate as an application identity against any tenant. We can directly observe service-principal state only within tenants we operate; the basis for the statement that it is not operational anywhere is the absence of any credential on the registration, and a customer administrator can corroborate it by confirming that no Bolde Sentry service principal exists in their own tenant. We disclose the registration because it exists and an administrator auditing our publisher will encounter it. Do not treat any Sentry capability as available. Sentry consent and credentials are forthcoming; see Section 11.

3.6 Internal, single-tenant applications. Three further registrations are single-tenant to Agentic Secure Group Inc.'s own Microsoft 365 tenant. They are not multi-tenant, they cannot be consented into a customer tenant, and they will not appear on a customer consent screen: Bolde Core — ASG Internal Operations (400 roles, scoped entirely to our own tenant), Bolde Meet — Teams Meeting Assistant, and Bolde Agent — Teams Bot. Each is registered with a single-tenant sign-in audience. They operate on our data, not yours.

3.7 How to verify this page. Do not take our word for any of the above. Before consenting, an administrator should:

• Read the Microsoft consent screen in full and confirm the application ID shown matches the ID listed here for the application being installed.
• Confirm the consent screen shows the publisher as verified under Microsoft Partner ID 7086299 (Mojave Research Inc.).
• After consent, review the granted permission set in the Microsoft Entra admin center under Enterprise applications → Permissions, filtered to the application ID.
• Enumerate the declared manifest directly — for example GET /v1.0/applications?$filter=startswith(displayName,'Bolde')&$select=appId,displayName,signInAudience,requiredResourceAccess — and count requiredResourceAccess entries by resource and by type. This is the query from which the counts in Sections 3.1–3.5 are derived.
• Enumerate what was actually granted in your own tenant with GET /v1.0/servicePrincipals/{id}/appRoleAssignments and …/oauth2PermissionGrants, and compare against Sections 3.1–3.6.

If anything you see at consent does not reconcile with this page, stop and contact security@bolde.ai. We commit to treat a discrepancy between this page and the deployed registrations as a security incident in our own process, not a documentation defect, and to correct this page under Section 16 with a dated entry.

4. Privileged and Destructive Capability.

This section exists because a customer cannot give informed consent to Bolde Control without it. We state the capability first and the governance second, in that order, deliberately.

4.1 What can happen. Where a customer administrator has consented to Bolde Control (ba2d80a5-2b27-470f-905e-827f2630af75), the Service is technically capable of taking the following actions in that customer's tenant:

• Remotely wiping or retiring a managed device, via DeviceManagementManagedDevices.PrivilegedOperations.All. A wipe can result in loss of data resident on the endpoint. Depending on the device and its configuration, that loss may be permanent.
• Assigning or removing directory roles, via RoleManagement.ReadWrite.Directory—including roles that confer administrative authority.
• Creating or modifying application registrations and their credentials, via Application.ReadWrite.All — held by both Bolde Control and Bolde Connect. Because this permits writing credentials to other application registrations, it is a privilege-escalation path and should be evaluated as such.
• Creating or modifying Conditional Access policies, via Policy.ReadWrite.ConditionalAccess—which can change who is able to sign in and under what conditions.
• Modifying tenant domains, via Domain.ReadWrite.All.
• Creating, enabling, disabling, deleting, restoring and re-credentialing agent identities, via the Entra Agent ID lifecycle roles.
• Writing directory objects — users, groups, group membership and organization properties — via Directory.ReadWrite.All, User.ReadWrite.All, Group.ReadWrite.All, GroupMember.ReadWrite.All and Organization.ReadWrite.All. This capability is not confined to Bolde Control; Bolde Connect declares the same permissions.

4.2 What binds us today. The following are in place now, and we state them as binding commitments rather than as description:

• Separate, declinable consent. Device wipe and retire, directory-role assignment, Conditional Access policy modification, domain modification and tenant-wide agent lifecycle authority do not exist in a tenant that has not consented to Bolde Control. Two capabilities in Section 4.1 are the exception: Application.ReadWrite.All is also declared by Bolde Connect, and directory-object write is conferred by Bolde Connect's Directory.ReadWrite.All. Declining Bolde Control does not withhold those two. Declining Bolde Control is a supported configuration and does not disable content functionality delivered through Bolde Connect or Bolde Ingest, and we commit not to condition any content functionality, support, data return or offboarding on consent to Bolde Control.
• Unilateral revocation. A customer administrator can delete any Bolde enterprise application from the tenant at any time, without notice to us and without our cooperation, and the capability that registration carried ends at that moment. Microsoft enforces this; we cannot prevent it. We commit not to seek, request or accept any arrangement that would make revocation contingent on our cooperation. See Section 5.
• Action only within customer-configured scope. The set of assets against which the Service is permitted to take administrative or destructive actions is configured by the customer under the applicable agreement, and the Service operates on rules the customer defines. We commit to execute administrative and destructive actions only within the scope the customer has configured. Administrative and destructive actions are Processing carried out on the customer's documented instruction; see the Data Processing Addendum.
• Privilege ceiling — a covenant, not a technical barrier. We commit that Bolde will not assign to itself, or accept, the Global Administrator, Privileged Role Administrator or Application Administrator directory roles in a customer tenant. This is a covenant about our conduct. It is not enforced by a technical control today—RoleManagement.ReadWrite.Directory and Application.ReadWrite.All are technically sufficient to defeat it, which is precisely why we state it as a binding commitment and why the immutable, customer-accessible attribution record listed in Section 11 is forthcoming.
• Independent logging under the customer's control. Administrative actions taken through Microsoft Graph are recorded in the customer's own Microsoft 365 unified audit log, which is under the customer's control and independent of us. We commit not to disable, suppress, purge or alter a customer's unified audit log configuration or its contents.
• Accurate capability disclosure. We commit to keep Section 3 reconciled to the deployed registrations, and not to request or exercise permissions beyond those disclosed in Section 3 without updating this page first.

4.3 What does not govern it yet. We want this unambiguous. As of the “Last updated” date, the following controls do not exist. Nothing on this page, in our documentation, or in our marketing should be read to suggest that any of them is in place, and none of them may be relied on:

• There is no per-instance approval gate. Authorization is granted at the category and configuration level. There is no out-of-band confirmation against a rendered list of specific target devices or objects immediately before an action, no mandatory delay window, no self-service abort during such a window, and no independent second approver. Forthcoming.
• There is no pre-action snapshot or escrow. The Service does not capture recoverable state before executing a destructive action, and we cannot undo a completed destructive action. A destructive action may therefore be irreversible. Forthcoming.
• There is no technical restriction preventing wipe of a customer's personally-owned devices. The distinction between corporate-owned and personally-owned devices in a customer tenant is not enforced in code as a hard prohibition. Our internal workforce device policy described in Section 9.1 governs our own personnel devices only and is not a product control. Forthcoming.
• There are no individually-assented end-user device terms. Device enrollment does not require, and is not gated on, an in-product acknowledgment recorded against each individual end user. Forthcoming.
• Native legal hold state is not an automatic block. Although Bolde Control holds Purview and eDiscovery permissions sufficient to query hold state, the Service does not treat that state as a non-overridable technical prohibition on destructive action. Forthcoming.

Until those controls exist, customers should scope destructive-action authority conservatively—to corporate-owned, fully managed devices—and should treat the configuration of that scope as a privileged administrative decision inside their own change-control process.

5. Consent, Publisher Verification, and Revocation.

• Administrator consent is required. Every customer-facing Bolde application requires a privileged administrator in the customer's organization to affirmatively grant consent before Bolde can access anything. Microsoft enforces this; we cannot bypass it.
• Publisher verification. All eight Bolde application registrations are publisher-verified under Mojave Research Inc., Microsoft Partner ID 7086299. Verified publisher status appears on the Microsoft consent screen. An application claiming to be Bolde that does not show this verified publisher, or whose application ID is not listed in Section 3, is not ours—do not consent to it, and please report it to security@bolde.ai.
• Granular consent. Because capability is split across registrations, consent is granular at the application level. A customer may consent to Bolde Ingest alone, or to Bolde Ingest and Bolde Connect while declining Bolde Control; the applications consented to are the only ones that exist in that tenant. What each choice does and does not withhold is stated in Sections 2.1 and 3.
• Customer-controlled revocation. Each application lives in the customer's own Entra ID tenant. A customer administrator can revoke access immediately by deleting the relevant Bolde enterprise application from the tenant, or by deleting all of them. No action by, notice to, or cooperation from any member of the ASG ecosystem is required for revocation to take effect, and we commit not to condition support, data return, or offboarding on a customer maintaining consent.
• Forthcoming — permission-by-permission consent disclosure. An in-product disclosure that renders every requested permission, application by application, at the moment of administrator consent, and records the consenting administrator's acknowledgment against the exact permission manifest presented, does not exist today. Today, the Microsoft consent screen and this page are the disclosure.

6. Data Handling and Isolation.

• Per-tenant isolation. We commit that each customer's data is processed and segregated on a per-tenant basis. One customer's data, control-plane objects and security signals are not commingled with, or made accessible to, another customer.
• Data minimization within a broad permission surface. Holding a permission is not the same as exercising it. We commit that the Service reads and retains only what is necessary for the functions a customer has engaged us to perform. We state plainly that this is a binding commitment about our behavior rather than a technical limit imposed by the permission set.
• No AI training on customer data. We commit that we do not and will not use customer data to train, fine-tune, or benchmark any artificial-intelligence or machine-learning model, including our own. Customer data is processed only to provide the Service to that customer and on that customer's documented instructions, and is not sold, shared, or used for any independent purpose. This commitment extends to control-plane objects and security signals.
• Deletion on offboarding. Because the Bolde applications live in the customer's own tenant, deleting them stops all further access immediately. Following termination or revocation, we will delete or de-identify the customer data we hold within the period described in the applicable agreement and our Privacy Policy, except where we are required to retain it by law or for legitimate security and audit purposes.
• Encryption in transit. We commit that all connections to Microsoft Graph, to our infrastructure, and to the Site are served exclusively over TLS (HTTPS) with modern cipher suites.
• Encryption at rest. Data we store is encrypted at rest using the encryption provided by our infrastructure and storage providers.
• Secrets in a vault, never in source. We commit that application credentials and other secrets are held in a dedicated secrets manager and are not committed to source code, configuration files, or version control.

7. Authentication, Credentials, and Access.

• Per-tenant, per-application authentication. Bolde authenticates to each customer tenant independently, per application registration, using the OAuth 2.0 client-credentials flow for application permissions. Access is scoped to the tenant that granted consent for that application.
• Delegated access is bounded by the user. Where Bolde Connect operates under a delegated scope—including its 33 delegated Entra Agent ID scopes—the effective authority is the intersection of the granted scope and the signed-in user's own rights. Microsoft enforces that ceiling.
• Credential handling. Application credentials are stored in our secrets manager, are not embedded in source code, and are held per application. Bolde Sentry has no credential provisioned at all, which is why it is non-operational, and Bolde Keeper has no credential of any kind; see Sections 3.4 and 3.5.
• Least-privilege personnel access. We commit that access to systems and data by our personnel is restricted to those who need it for their role, on a least-privilege basis.
• Forthcoming — workload identity federation. Per-tenant workload identity federation, allowing authentication using short-lived federated credentials rather than a long-lived application secret, does not exist today.
• Forthcoming — customer-held, customer-revocable agent credentials. An architecture in which agent credentials are generated in and held by the customer's own tenant, are non-exportable, and can be revoked by the customer unilaterally without our cooperation, does not exist today.

8. Infrastructure and Sub-Processors.

The Site and its supporting infrastructure run on a small, deliberately chosen set of providers. The authoritative and current sub-processor list for the Service is maintained under the Data Processing Addendum; the list below covers the Site and its immediate supporting services.

• Cloudflare, Inc. — Edge infrastructure (Workers and Pages), the D1 database, Turnstile bot detection, and cookieless Web Analytics. Traffic is served through Cloudflare's network, which also provides TLS termination and distributed-denial-of-service protection. Cloudflare's privacy policy is available at cloudflare.com/privacypolicy.
• Resend, Inc. — Transactional email for verification, confirmation, and related notices.
• Twilio Inc. — If you opt in to SMS, we use Twilio Verify to send and verify one-time codes.
• Microsoft Corporation. Customer tenant data resides in the customer's own Microsoft 365 tenant under the customer's own agreement with Microsoft. We access it through Microsoft Graph under the consent the customer grants; we do not relocate it out of Microsoft's platform except as necessary to provide the Service and as described in the Data Processing Addendum.

For the full description of how the Site collects and processes personal information, including the role of each sub-processor, see our Privacy Policy. We commit to update the sub-processor list when we add or change material providers.

9. Application and Operational Security.

• Rate limiting. Form submission and API endpoints are rate-limited to detect and slow abuse.
• Bot mitigation. Cloudflare Turnstile is used on customer-facing forms to distinguish human visitors from automated submissions.
• Single-use, time-limited tokens. Email verification and similar links use single-use tokens that expire after a short window.
• Logging and audit. We maintain operational logs, and administrative actions taken through Microsoft Graph appear in the customer's own Microsoft 365 unified audit log, which the customer controls independently of us.
• Least-privilege personnel access. Our personnel access to systems and data is restricted to role necessity.
• Separation of registrations as an operational control — and its limit. Because the highest-consequence permissions are confined to Bolde Control, a compromise of the Bolde Ingest or Bolde Keeper identities does not yield directory-role, Conditional Access policy, agent-lifecycle or device authority. It does not follow that Bolde Control is the only privileged identity: Bolde Connect declares directory-object and application-registration write and should be threat-modelled as a privileged identity.

9.1 Internal workforce device policy — our own devices, not yours. Bolde maintains an internal Bring-Your-Own-Device policy published to its workforce, governing how our own personnel devices are managed. Under that policy, personally-owned devices used by our personnel are limited to application-level protection: corporate data is confined to protected applications and is removable from those applications without a device-level action, and device-level management actions, including wipe and retire, are directed at corporate-owned devices. We describe the architecture of that policy here; we do not represent that any particular enforcement assignment is presently active.

This is an internal control over our own workforce and our own devices. It is not a product control. It does not constrain what the Bolde Control application can do inside a customer's tenant, it confers no rights on any customer or on any customer's personnel, and it must not be read as a guarantee about how a customer's devices are treated. The technical restriction preventing wipe of a customer's personally-owned devices does not exist today and is listed as forthcoming in Sections 4.3 and 11.

10. Compliance Posture.

The following describes our current posture accurately; it does not claim certifications or audits we have not completed:

• SOC 2 / ISO 27001 — forthcoming, not certified. We design our controls with the objectives of SOC 2 and ISO/IEC 27001 in mind and are working toward formal attestation. As of the “Last updated” date above, we have not obtained a SOC 2 report or an ISO 27001 certificate, no such audit has been completed, and we make no representation that we hold either. We describe these as forthcoming objectives, not commitments to a particular outcome or date, and we commit to update this page only if and when that status actually changes. Until then, please do not rely on any SOC 2 or ISO 27001 status.
• Privacy law alignment. Our handling of personal information is designed to align with the California Consumer Privacy Act of 2018 as amended by the California Privacy Rights Act (Cal. Civ. Code §§ 1798.100–1798.199.100) and the Colorado Privacy Act (C.R.S. §§ 6-1-1301 to 6-1-1313), among other applicable United States state privacy laws. See the Privacy Policy for details.
• Automated administrative action — stated accurately. Bolde does take automated action inside a customer's environment under rules the customer configures; it is not a passive reporting tool. The Company does not itself make, and does not hold itself out as making, decisions that produce legal or similarly significant effects concerning consumers in areas such as employment, lending, housing, healthcare or education. Where a customer uses Bolde output as an input to a decision of that kind, the customer is the decision-maker and is responsible for the notice, opt-out, access and risk-assessment obligations that attach to it, including under Cal. Civ. Code §§ 1798.100–1798.199.100 and C.R.S. §§ 6-1-1301 to 6-1-1313.
• Biometrics. The Service does not capture, store or use biometric identifiers or biometric information as those terms are defined by the Illinois Biometric Information Privacy Act (740 ILCS 14/1 et seq.) and Tex. Bus. & Com. Code § 503.001. Microsoft Graph does not expose the underlying biometric template to any application, including Bolde Control (ba2d80a5-2b27-470f-905e-827f2630af75); what a Bolde application can read is metadata indicating whether a user has enrolled a biometric authentication method, which is not a biometric identifier or biometric information. Technical enforcement of this exclusion in code is forthcoming; see Section 11.

11. Forthcoming Controls — Not Yet in Place.

Consolidated here so that a reader does not have to assemble it from the sections above. Every item below does not exist as of the “Last updated” date. None of them may be relied on in a purchasing, consent, or risk-acceptance decision, and none of them is a commitment as to scope or date. We list target behavior, not target dates, because we will not commit to dates we cannot control.

• Per-instance approval gating. Out-of-band confirmation by a designated administrative contact against a rendered, itemized target list; a mandatory delay window with a self-service abort; and a second independent approver above a defined threshold, before a privileged or destructive action executes. Authorization today is granted per category and configuration, not per instance.
• Pre-action snapshot and escrow. Capture of recoverable state before a destructive action, retained for a defined period, with restoration available at our cost. Until this exists, a destructive action may be irreversible and we cannot undo a completed one.
• Technical restriction preventing wipe of a customer's personally-owned devices. A code-level prohibition on full-device wipe or factory reset of any device in a customer tenant flagged as personally owned, limiting action on such devices to selective removal of work data. Our internal workforce policy at Section 9.1 is not this control.
• Individually-assented end user device terms. Enrollment technically gated on a recorded, versioned, per-user in-product acknowledgment.
• Automatic legal hold and preservation block. Querying the connected service's native hold state and treating it as a non-overridable prohibition on destructive action.
• Permission-by-permission consent disclosure with a recorded assent artifact tied to the consenting administrator and the exact permission manifest presented.
• Customer-tenant-held, non-exportable, unilaterally revocable agent credentials.
• Immutable, customer-accessible approval and attribution record for every administrative and destructive action, including initiating human, governing rule, acting identity and correlation identifier.
• Per-tenant workload identity federation in place of long-lived application secrets.
• Technical enforcement of the biometric exclusion described in Section 10.
• Bolde Sentry consent and credentials. Bolde Sentry holds no credential and no consented application role assignments. Security posture and threat operations capability is forthcoming in its entirety.
• SOC 2 and ISO/IEC 27001 attestation.

12. Vulnerability Disclosure.

We welcome reports from security researchers and operate a coordinated, responsible disclosure process. This Section 12 is the authorization and policy of the ASG ecosystem for security research; it is not an offer of, or a promise to pay, any bug-bounty reward.

• How to report. Email security@bolde.ai with a description of the issue, the steps to reproduce it, and any supporting material. Please do not report suspected vulnerabilities through public channels.
• Coordinated disclosure. We ask that you give us a reasonable opportunity to investigate and remediate before any public disclosure, and that you do not disclose a vulnerability publicly until we have coordinated a resolution with you.
• In scope. This authorization covers good-faith testing of the bolde.ai Site and the systems the ASG ecosystem operates in support of it. It does not extend to, and you are not authorized to test: any customer's Microsoft 365 tenant or data; any Bolde enterprise application as installed in a customer tenant; Microsoft, Cloudflare, Resend, Twilio, or any other third-party platform or sub-processor; or any system you do not own or are not expressly authorized to test. Testing of third-party systems is governed by those parties' own policies, and this policy grants no authorization on their behalf.
• Out of bounds. The following are outside this policy and are not authorized: accessing, modifying, exfiltrating, or destroying data that is not your own; degrading, disrupting, or denying service (including denial-of-service testing, automated load or stress testing, or resource exhaustion); social engineering, phishing, or physical attacks against any member of the ASG ecosystem, its personnel, or its customers; spam; and any act that violates applicable law.
• Good-faith safe harbor. If you make a good-faith effort to comply with this policy — including staying within the scope above, avoiding privacy violations, data destruction, and degradation of the Service, accessing only the minimum data necessary to demonstrate the issue, not exploiting a vulnerability beyond what is needed to prove it exists, and giving us a reasonable time to remediate before disclosure — then the ASG ecosystem will consider your security research to be authorized conduct, will not initiate or recommend a civil claim or referral for prosecution against you in connection with that research, and, to the extent your conduct triggers enforcement rights under the Computer Fraud and Abuse Act (18 U.S.C. § 1030), Cal. Penal Code § 502, or a comparable state computer-crime statute, waives those rights for that conduct. This safe harbor is given by the ASG ecosystem only; it does not bind, and cannot waive the rights of, any customer or third party, and it does not apply to conduct that falls outside this policy. If legal action is brought against you by a third party for activity that complied in good faith with this policy, we will take reasonable steps to make that compliance known.
• Our response commitment. We will acknowledge receipt of your report and work in good faith to triage and remediate confirmed vulnerabilities, keeping you reasonably informed of our progress. We do not commit to a fixed acknowledgment or remediation deadline; timing depends on the nature, severity, and complexity of the issue.
• Documentation accuracy is in scope. A material discrepancy between the capability disclosed on this page and the capability actually held by a Bolde application registration is a reportable finding, and we commit to treat it as one.

13. Incident Response and Breach Notification.

We maintain processes to detect, investigate, contain, and remediate security incidents. If we determine that a security incident has resulted in the unauthorized access to or acquisition of personal information or customer data that we hold, we will notify affected customers and, where we are required to do so, affected individuals, in the manner and within the timeframes required by applicable law—including, where applicable, Cal. Civ. Code §§ 1798.29 and 1798.82, C.R.S. § 6-1-716, and N.Y. Gen. Bus. Law § 899-aa. Our notice will, to the extent then known and permitted by law, describe the nature of the incident, the categories of information involved, and the measures we are taking.

Destructive action incidents — a binding commitment. Where a destructive action is executed in error, outside the customer's configured scope, or otherwise without proper authorization, we commit to notify the affected customer within 24 hours of determination and to provide the target list, the authorization record on which the action was executed, and any restoration options then available, whether or not the event also qualifies as a security incident. This commitment is made on this page and is also carried in the Data Processing Addendum. Because pre-action snapshot and escrow does not exist (Sections 4.3 and 11), the restoration options available may be none.

Except as stated above, we do not commit on this page to any specific notification deadline shorter than what applicable law requires; the governing timeframe is the one set by the applicable law or by the agreement between the customer and the Company. Where a customer is the controller of its own tenant data, the customer is responsible for any notifications it must make to its own users, employees, or regulators, and we will provide the customer with reasonable cooperation and the information within our possession that the customer needs to meet those obligations. Notification of, or a response to, an incident by any member of the ASG ecosystem is not an acknowledgment of fault or liability.

14. Shared Responsibility.

Securing a Microsoft 365 environment is a shared responsibility between the customer and the Company. Each side controls a different part of the environment, and each is responsible for the part it controls:

• The customer controls its own Microsoft 365 tenant, including its directory, its identity and access management (such as administrator accounts, Conditional Access, and multi-factor authentication), and its tenant security configuration. The customer is the controller of its own tenant data and is responsible for: deciding which Bolde applications to consent to, and whether to consent to Bolde Control at all, having reviewed Sections 4 and 5; ensuring it has the authority and any internal approvals, employee notices, works council consultations, or other consents required in its jurisdiction before connecting its tenant and before enabling administrative or destructive action; defining the scope of assets against which administrative or destructive actions may be taken, and keeping that scope current; configuring what data exists in the workloads Bolde can reach; managing its own users, devices, and offboarding; and revoking access at any time by deleting the relevant applications from its tenant, which it may do without notice to or action by any member of the ASG ecosystem.
• The Company is responsible for: disclosing its application permission surface accurately and keeping this page reconciled to the deployed registrations; not requesting or exercising permissions beyond those disclosed in Section 3; maintaining separation of duties across registrations; isolating tenant data on a per-tenant basis; protecting credentials; encrypting data in transit and at rest; limiting personnel access on a least-privilege basis; executing administrative and destructive actions only within the scope the customer has configured; and operating the disclosure and incident-response processes described above.
• Allocation. No member of the ASG ecosystem is responsible for the security of, or for configuration choices made within, a customer's Microsoft 365 tenant or any other system the customer controls, and the customer's decision to grant or maintain consent does not transfer that responsibility to any member of the ASG ecosystem. Nothing in this Section limits or disclaims responsibility for our own affirmative acts. The definitive allocation of responsibilities and liability for a paid engagement is set out in the applicable agreement between the customer and the Company.

15. Contact.

For security questions, vulnerability reports, or to request information about our security practices, contact us at:

• Security: security@bolde.ai — include “Security Disclosure” in the subject line for vulnerability reports
• Privacy: privacy@bolde.ai — for privacy requests
• Legal and notices: legal@bolde.ai
• Postal mail: Agentic Secure Group Inc., c/o Hedberg Law, 5944 S Kipling Pkwy, Suite 200, Littleton, CO 80127
• Contracting entity: Agentic Secure Group Inc., a Delaware C-Corporation, trading as Bolde
• Microsoft publisher of record: Mojave Research Inc. — verified publisher, Microsoft Partner ID 7086299

16. Changes to This Page.

We may update this Security page as our applications, permissions, infrastructure, or compliance posture change. When we make material changes —and in particular any change to the application permission disclosure in Section 3, the capability disclosure in Section 4, or the forthcoming-controls list in Section 11—we commit to update the “Last updated” date at the top of this page, record the change in a dated entry, and, where appropriate, post a prominent notice on the Site. We commit to correct this page rather than quietly rewrite it. Non-material changes, such as clarifications or typographical corrections, will be effective upon posting.

Except for the binding commitments identified on this page, which are incorporated by reference into our Terms of Service and our Data Processing Addendum, this page is informational and does not by itself create contractual commitments. The security obligations that apply to a paid engagement are governed by the applicable agreement between the customer and the Company, including the Terms of Service and the Data Processing Addendum. Nothing marked forthcoming in Section 4.3 or Section 11 is a commitment, and no member of the ASG ecosystem warrants that any forthcoming control will be delivered, delivered in the form described, or delivered by any date.