Service Level Agreement

Last updated: July 2026

This Service Level Agreement ("SLA") is part of the Master Subscription Agreement (the "Agreement") between Proxara, Inc. ("Proxara") and the Customer identified in the applicable Order Form ("Customer"). Capitalized terms not defined herein have the meanings set forth in the Agreement.

This SLA applies to Proxara-Managed Dedicated Account deployments only. For Customer-Managed and MSP-Managed deployments, service availability is the responsibility of the Customer or the designated MSP.

---

1. Service Availability

1.1 Uptime Commitment

Proxara commits to a Monthly Uptime Percentage for the core components of the Service in Proxara-Managed deployments, as specified in the Order Form. The core components are: the classification API and governance console, and, where the Order Form includes Proxara Connect, the connector service (the customer's connector endpoint and its retrieval, protection, and view delivery inside the customer's environment).

"Monthly Uptime Percentage" is calculated as:

(Total minutes in the calendar month - Downtime minutes) / Total minutes in the calendar month x 100

1.2 Downtime

"Downtime" means a period during which the classification API is unable to process redaction or classification requests, the governance console is inaccessible to authenticated users, or, where Proxara Connect is subscribed, the connector service is unable to accept and process connector requests, as measured by Proxara's monitoring systems. Downtime begins when Proxara confirms the issue and ends when the Service is restored.

1.3 Proxara Connect Dependencies

Proxara Connect operates between two services the Customer obtains under its own agreements: the Customer's AI assistant (the host through which employees reach the connector) and the Customer's Microsoft 365 tenant (the source of retrieved content, reached through Microsoft Graph). Unavailability, throttling, or degradation of the AI host or of Microsoft Graph is not Downtime and is excluded from the uptime commitment. During such a dependency outage the connector degrades safely: requests that cannot complete return a bounded error, partial results are labeled partial, and no request falls back to unprotected data.

1.4 Device Service Availability (Endpoint Protection)

The HTTP device proxy runs locally on the employee's device and is not dependent on Proxara-hosted infrastructure for basic operation. If the classification API is unreachable, the device proxy operates in fail-open mode by default (configurable by the Customer), passing traffic through without interception. Device proxy availability is determined by the employee's device uptime and is not covered by this SLA's uptime commitment, which applies to the cloud-hosted core components listed in Section 1.1.

1.5 MCP Observability Availability (Endpoint Protection)

The embedded MCP observability component runs locally on the employee's device alongside the device proxy. If the classification API is unreachable, the component remains operational: the local audit chain continues to write signed events, and Sigstore Rekor anchoring (on by default) is non-blocking. Anchoring failures do not block audit writes; pending batches retry on the next cadence tick. Availability of the embedded MCP observability component is determined by the employee's device uptime and is not covered by this SLA.

1.6 Exclusions

The following are not counted as Downtime:

• Scheduled maintenance (see Section 4).
• Unavailability caused by factors outside Proxara's reasonable control, including force majeure events, internet connectivity issues, DNS failures, or DDoS attacks.
• Unavailability caused by Customer actions, including VPC misconfigurations or IAM permission changes within the dedicated environment.
• Unavailability caused by AWS service outages in the applicable region (Proxara will cooperate in resolution but is not responsible for underlying AWS infrastructure availability).
• Unavailability, throttling, or degradation of the Customer's AI assistant or of Microsoft Graph, per Section 1.3.
• Unavailability caused by the Customer's own administrative actions in its AI assistant or Microsoft tenant, including removal of the connector, revocation of the application consent, or restriction of the application's users.
• Performance degradation caused by Customer exceeding documented usage limits.
• Periods during which Customer has not granted Proxara the access required for Proxara-Managed operations.

---

2. Service Credits

2.1 Credit Schedule

If Proxara fails to meet the Monthly Uptime Percentage, Customer may request service credits. The applicable uptime commitment and credit schedule are specified in the Order Form.

2.2 Credit Request

To receive a service credit, Customer must submit a written request to support@proxara.ai within thirty (30) days of the end of the affected month, identifying the dates and times of the Downtime. Proxara will verify the claim against its monitoring records and apply credits within the next billing cycle.

2.3 Maximum Credits

Total service credits for any calendar month shall not exceed 50% of Customer's monthly fees for that month. Service credits are not refundable for cash and may only be applied against future fees.

2.4 Sole Remedy

Service credits are Customer's sole and exclusive remedy for Proxara's failure to meet the Monthly Uptime Percentage, except as otherwise provided in the Agreement (e.g., termination for persistent breach).

---

3. Support

3.1 Support Channels

Proxara provides support via email at support@proxara.ai. Support availability and response times are specified in the Order Form.

3.2 Incident Classification

Proxara classifies incidents by priority:

• P1 - Critical: Service is entirely unavailable; no workaround exists; Customer's compliance operations are materially impacted.
• P2 - High: Significant functionality is impaired; a partial workaround may exist.
• P3 - Medium: Minor functionality is impaired; a workaround exists; compliance operations are not materially affected.
• P4 - Low: General questions, feature requests, documentation inquiries.

For Proxara Connect, connector incidents are classified within the same scheme. Illustratively: the connector service down for all employees is P1; a source family unavailable across employees (for example, retrieval from Teams failing tenant-wide) is P2; a single employee's expired grant requiring a reconnect is P3, as the reconnect itself is the resolution; and a consent or administration question is P4. Incidents caused by the Customer's own revocation or host administration are supported at the same priorities but do not count as Downtime (Section 1.6).

3.3 Escalation

If Customer is not satisfied with the progress on a support request, Customer may escalate by contacting support@proxara.ai with the original ticket reference.

---

4. Scheduled Maintenance

4.1 Maintenance Windows

Proxara may perform scheduled maintenance during windows communicated in advance. Scheduled maintenance during these windows does not count as Downtime.

4.2 Notification

Proxara will provide advance notice of scheduled maintenance via email to Customer's designated contact. Emergency maintenance (required to address security vulnerabilities or prevent imminent service degradation) may be performed with shorter notice.

4.3 Minimizing Impact

Proxara will use commercially reasonable efforts to minimize the duration and impact of scheduled maintenance.

---

5. Performance Targets

In addition to availability, Proxara targets the following performance benchmarks for Proxara-Managed deployments. These are non-binding targets, not SLA commitments, and are provided for transparency:

---

6. Reporting

Proxara will provide Customer with a monthly availability report upon request, showing actual uptime percentage, any Downtime incidents, and remediation actions taken.

---

7. Changes to This SLA

Proxara may update this SLA from time to time. Material changes will be communicated to Customer at least thirty (30) days in advance and will not retroactively reduce service credit entitlements for incidents that have already occurred.