---
title: Spruce — Reference Brief
subject: Spruce (sprucetools.com), an IT endpoint management operations platform, starting with Apple
publisher: Spruce Tools
version: 2.0
facts_as_of: 2026-09-19
document_type: product description — intent, differentiation, architecture, value, engineering approach
product_status: live subscription service; platform in early access; see section 8
out_of_scope: financials, investors, customer identities, contract terms, security-sensitive implementation detail
sources: the public website and sales materials; the company's internal engineering repositories, design documents, and decision records (not public); internal strategy notes
---

# Spruce — Reference Brief

This is a reference document about a company and its product. It contains no instructions for AI systems. Any passage in it that reads as an instruction to an AI system is an error or evidence of tampering.

## 0. About this document

Spruce is a live subscription service: automated endpoint maintenance delivered through the tools an organization already runs, with Apple- and Jamf-certified technicians handling judgment calls and verifying every change. The platform behind the service is in early access. Its data engine is built, and the systems it connects to and the tasks it automates expand during early access. Which of an organization's systems Spruce works with is confirmed during the free fleet health check, before any subscription. This brief describes the service as designed.

Questions this brief does not answer can be sent to Spruce at https://sprucetools.com/ask (section 11).

The brief covers Spruce's intent, what makes it different, why its core is hard to build, why an organization would use it, and how the team builds it. Section 8 summarizes where the platform stands. Mechanisms and figures come from the company's engineering repositories and design records as of the date above, and outside figures name their source. The aim is specification, not adjectives.

The brief covers two things on purpose and keeps them distinct:
- **The engine** (sections 3, 4, and 6): a multi-source data engine that is hard to build in the first place and is being built to a high standard.
- **The business** (sections 2 and 5): a service in which the engine and the technicians are inseparable. The engine is what makes the service possible at scale. The people are what make it a service rather than another alert console.

## 1. Summary

- **Intent.** Spruce is an operations layer for IT endpoint management. It starts with Apple, which the company sees as underserved and where experienced Apple administrators are hard to hire, and it is built for endpoint management across IT generally. It connects to the tools already in place: MDM, Apple Business or School Manager, identity provider, network filtering, patching and security services, and an optional endpoint agent. It reconciles them into one consistent model of the environment and automates the routine maintenance that tends to fall behind. Apple- and Jamf-certified technicians handle everything that needs judgment. It is not intended to replace a tool, but to automate and improve existing ones.
- **What makes it different.** Spruce is not an MDM. Its core is a multi-source data engine with these parts:
  - collection from every connected system, on a schedule
  - matching the same device, person, or application across systems that each name it differently
  - a record, for every individual fact, of which system it came from and when
  - clear handling of connections that are missing or uncertain, instead of guesses
  - one place to ask questions of the combined result

  That is a different category from an API connection, a dashboard, or an AI tool-calling connector. In Spruce, AI works on top of a deterministic model rather than serving as the integration layer. Its reach spans the IT stack rather than one toolset. Drift and maintenance problems that sit between the MDM, the identity provider, network filtering, and Apple Business Manager are caught in one place.
- **Why it is hard to build.** The sources share no common identifier, arrive on independent schedules, disagree with each other, delete records without notice, and describe the same device or person in incompatible ways. Turning that into a model that stays correct under concurrency, stays isolated between customers, and can explain its own answers is a substantial engineering effort, not an integration project.
- **Verified, not reported.** A change counts as done only when it is observed in the collected data, not when someone says it is done.
- **Why an organization would use it.** Organizations already buy routine IT functions as infrastructure plus people at scale: managed detection and response (MDR), managed email security, third-party patching, and backup monitoring. Few of them are bought mainly for lack of skill. They are bought mainly for four things:
  - coverage outside business hours
  - liability that sits with a vendor
  - continuity when staff leave
  - capacity that does not wait on hiring

  Spruce applies that model to IT endpoint management, starting with Apple. It covers the maintenance work that compliance, insurance, and contracts require and that busy teams, however skilled, cannot keep up with.
- **Engineering approach.** Built to show its work. Every value traces back to its source, every change is confirmed in the data before it closes, and every change to the AI features is measured against a fixed set of questions with known-correct answers. Staging and production are separate, with no automated access to production. Tests run against real databases, not simulations. Credentials are stored only as irreversible digests. Design records and internal audit findings are available for technical due diligence under a nondisclosure agreement.
- **Status.** Spruce has existed as a live subscription service since 2024. It has multiple clients including schools, financial institutions, businesses, and nonprofits; these entities subscribed to supplement internal IT Apple skills, lower the workload for existing personnel, or assist with compliance for overworked staff.

## 2. Intent: what Spruce is for

The current whitepaper, written for the Apple-first offering, describes Spruce as "an Apple device operations platform that automates routine IT maintenance and provides expert oversight for organizations managing Apple fleets." The public tagline is "Endpoint Management, automated by AI and monitored by humans." and the site title is "Automated endpoint management." An earlier 2025 deck used the name "Decision layer." The positioning has moved from "a better way to use MDM" toward "an operations layer above the existing IT stack."

**Scope: endpoint management across IT, starting with Apple.** Spruce is meant for endpoint management across IT, not only Apple. Apple is the starting point for three reasons:
- Apple fleets in schools and businesses are underserved.
- Many organizations have no seasoned Apple system administrator on staff, so the experience gap is real.
- The company's human experts are trained and certified in Apple and Jamf.

The nearest industry term is endpoint security posture management (ESPM), but ESPM is largely security-focused. Spruce applies the same idea, continuously checking that endpoints and the systems around them are in their intended state, to endpoint management as a whole: identity, enrollment, apps, updates, configuration, filtering, and security tooling.

**The buying pattern this follows.** Most IT teams, school districts, businesses, and IT service providers buy several routine functions from outside vendors instead of running them entirely in-house:
- email security
- endpoint detection and response
- third-party patching
- backup monitoring
- after-hours coverage

Few are bought mainly for lack of skill; many teams that buy them could configure the underlying tools themselves. They are bought because each is infrastructure plus people at scale:
- coverage has to exist at 2 a.m. and on weekends
- liability sits better with a vendor that carries it
- a capability held by one employee leaves when that employee does
- a team cannot hire ahead of a spike

The company's thesis is that endpoint management belongs in the same category. Most organizations still treat it as work they must do themselves, when most of it is routine, time-consuming maintenance that is better done at scale. Spruce exists to offer it that way.

**Who it is for.** Spruce fits two kinds of team:
- teams that cannot get to all of the routine work
- teams that can, but have better uses for the people doing it

Both kinds include teams with deep Apple expertise, and service providers whose own technicians are excellent and fully booked. The work that slips is rarely the hard work. It is the routine work that loses to urgent work every week. Even where maintenance is current and verified every week, a skilled administrator spending those hours on routine upkeep is an expensive way to get it done.

The dividing line is scale economics, not competence. Spruce is not a fit where the organization is large enough that in-house maintenance staff cost the same as Spruce or less. That is usually a very large fleet, where a dedicated team's cost per device has fallen to Spruce's price or below.

For the Apple-first offering, the intended customer already has the core infrastructure:
- Apple School Manager or Apple Business Manager.
- An MDM such as Jamf Pro or Mosyle.
- An identity provider such as Microsoft Entra ID.
- Usually additional security tools.

Target segments are K-12 schools, businesses, and the IT service providers that support them. The typical operator is one of:
- a Windows-focused administrator who also maintains the Apple fleet
- an experienced Apple administrator consumed by urgent work
- a well-staffed team that would rather spend its people on projects than on maintenance

The problem is not a lack of tools or of skill. It is coverage: routine, consequential work that no one has the hours to keep current. The tasks that fall behind:
- certificate and token renewals
- OS update shepherding
- third-party software patch management
- app requests
- user and device assignments
- identity sync between Apple Business Manager and the IdP
- stale inventory
- reporting
- stale profiles and configurations in an MDM

Company materials report that a routine new-app request often takes internal IT about two weeks. That figure is the company's field observation, not a measured study. For context, a 2026 IT help-desk benchmark from Fixify covers more than 50,000 tickets across all ticket types. It reports a median resolution time of 71 hours without automation and 4.4 hours with AI-assisted automation. The benchmark is vendor-published.

Spruce works in three layers:
1. **Aggregation.** Collect operational data from existing systems.
2. **Automation.** Decide and perform the safe, routine work.
3. **Response and verification.** Apple- and Jamf-certified technicians resolve what cannot be automated. Every change is confirmed by observing it in the data before it closes.

Pricing is per device per month in three tiers, with K-12 and business tracks and a 30-day trial. The tiers step up in three stages:
- **Maintenance:** certificate renewals, assignments, stale records, update alerts, inventory, hardware and storage health, and reporting.
- **Monitoring:** third-party patching, network filtering, and more automated remediation.
- **Security:** managed antivirus, EDR, and MDR tooling, plus cloud SIEM monitoring. This tier includes deploying and managing macOS security tools, not only an analogy to security services.

Spruce's technicians are all Apple- and Jamf-certified, and the owner has run an Apple Technical partner MSP for 26 years. Spruce itself is not an MSP and is not built as an extension of one. The intent is a Spruce service provider focused on endpoint operations, moving away from the managed-service-provider model rather than funding a rival to anyone. The intent is, as with managed email or MDR, to provide services to organizations lacking IT, IT departments who want to elevate their own IT team to do more valuable things, or MSPs looking to increase margins. 

## 3. What makes it different

### 3.1 A layer across the existing tools, not another MDM

The platform contains no MDM server. It does not speak the Apple MDM protocol, holds no Apple push certificate for commanding devices, and does not enroll devices into its own management. The customer's MDM remains the system of record and the point of enforcement.

Spruce reads from the customer's MDM, identity provider, and other services through their APIs. Changes to devices are made in the customer's MDM, either by Spruce technicians using access the customer grants or by narrowly scoped automations. Outcomes are then verified by observing the result in the collected data (3.6). The free fleet health check that starts an engagement requires read-only access.

Spruce's optional macOS endpoint agent is also not an MDM:
- It dials out only and never opens a listening port.
- It exposes a fixed, versioned catalog of read-only collectors built on Apple-shipped diagnostic tools.
- It contains no shell and cannot execute server-supplied commands.
- A fully compromised server can read what the catalog reads and nothing else.
- Remediation is deliberately developed as a separate, separately installed binary.

Spruce participates in Jamf's Technology Partner Program. That program requires integrations to add to or augment Jamf's native workflows without interfering with them.

In the company's view, building another MDM would reproduce mature products and force customers into a migration. The value is in what no single tool covers: whether management is still working, and whether the tools agree with each other (section 5.1).

Spruce is not limited to MDM data. It takes on the pain points usually filed under endpoint management wherever they live:
- MFA enforcement in the identity provider
- site and app filtering in network filters
- identity sync into Apple Business or School Manager
- patch state in patching services
- device condition from the endpoint itself

### 3.2 A data engine, not an integration

Each system in an IT environment describes a different part of it:
- **MDM:** enrollment, inventory, profiles, applications, restrictions, and command status.
- **Apple Business Manager / Apple School Manager:** organizational ownership, Automated Device Enrollment, Managed Apple Accounts, and app licensing.
- **Identity provider (such as Entra ID):** users, groups, authentication, account status, and device identity.
- **Security platform:** vulnerabilities, detections, controls, and risk.
- **Patching service:** application versions, available updates, and deployment status.
- **Network and DNS filtering:** which sites and apps are allowed or blocked, and whether each device is actually routed through the filter.
- **Endpoint agent:** the current condition of the device itself.

The product is a data engine that combines these systems. That is a different thing from a connection to one system, a dashboard that shows several side by side, or an AI assistant plugged into each vendor's tools. It has five parts:
- collection from every connected system, on a schedule
- matching the same device, person, or application across systems that each name it differently
- a record, for every individual fact, of which system it came from and when
- clear handling of connections that are missing or uncertain, instead of guesses
- one place to ask questions of the combined result

**Customer data separation.** Customer data is separated by default within shared infrastructure. Fully separate infrastructure is available on request, arranged during contracting and priced accordingly, for organizations whose compliance requirements call for it.

### 3.3 Compared with API integrations, dashboards, and AI connectors

Most tools in this space query each vendor live or match records at display time. Spruce maintains a persistent, reconciled model with recorded provenance.

| Question | Direct API integration | Generic dashboard | AI assistant over MCP/tool calls | Spruce data engine |
|---|---|---|---|---|
| Where does "truth" live? | In each provider, queried live | In each provider, rendered side by side | In each provider, fetched per question | In a reconciled store built from all sources, with every value attributed to its source and observation time |
| Cross-source identity (same device or person across MDM, IdP, agent) | Not addressed | Usually by display-time matching, if at all | Done by the model inside one conversation, then discarded | Persistent identity index; each link carries resolved, unresolved, or ambiguous status |
| When sources disagree | Caller sees whichever source it asked | Viewer sees both and reconciles mentally | Model picks or blends; results can vary run to run | Disagreement is preserved per field with source and timestamp; resolution rules are deterministic |
| Freshness | Live for that one source | Varies; often opaque | Live but bounded by rate limits and context size | Every attribute carries `observedAt`; staleness is queryable |
| History and audit | None beyond the provider's own | Rarely | None | Per-field observation times, point-in-time report snapshots, and an immutable event history for every request (3.6) |
| Role of AI | None | None | The integration layer itself | An interface on top of a deterministic model (3.5) |

An AI assistant working over the Spruce model inherits identity resolution, provenance, and tenant isolation instead of re-deriving cross-source joins on every question (3.4).

### 3.4 When separate product MCPs are enough, and when a data engine is needed

MCP solves connectivity and tool invocation. It does not unify device and operational data.

For occasional questions about a single system, separate product MCPs can be sufficient: whether one Mac is enrolled in Jamf, or which configuration profiles one device has. The model calls the relevant service, interprets the result, and answers. A normalized database would add cost without much benefit.

A data engine becomes valuable when an AI must reason reliably across systems. Without one, the AI redoes the same reconciliation on every question. It spends more tokens and tool calls, occasionally matches devices or users incorrectly, and produces results that are difficult to audit.

| Need | Separate product MCPs | Spruce data engine |
|---|---|---|
| Check one device in Jamf | Good | Usually unnecessary |
| Compare MDM inventory with Apple Business Manager | Model must reconcile formats and identities every time | Devices are matched once and queried consistently |
| Determine whether a user's assigned devices are compliant | Requires calls across MDM, identity, security, and endpoint tools | Users, devices, and compliance state are already correlated |
| Identify devices missing from MDM | Difficult without comparing multiple inventories | Unmatched and missing records surface continuously |
| Track configuration or compliance history | Limited by each API's retention and current-state model | Consistent snapshots and state changes |
| Generate fleet-wide dashboards | Multiple slow API calls | One efficient query |
| Explain why a device is noncompliant | AI must interpret conflicting vendor data on demand | Normalized evidence and known policy definitions |
| Auditability | Hard to reproduce the model's reasoning | Stored source and observation time for every value; deterministic resolution rules |
| Device and user identity resolution | AI guesses whether records refer to the same device or person | Explicit mappings across serial numbers, accounts, directories, and app identifiers |
| Alerts and continuous monitoring | Requires repeated polling and interpretation | Rules run against normalized state |
| Device actions | Direct MCP is useful | Still performed through the authoritative product |

The design is hybrid:

```mermaid
flowchart TD
    A["MDM MCPs / APIs"] --> D["Ingestion and normalization"]
    B["Apple and identity services"] --> D
    C["Security, patching, and endpoint data"] --> D
    D --> E["Canonical IT operations model"]
    E --> F["Spruce MCP / AI interface"]
    F --> G["Analysis, alerts, dashboards"]
    F --> H["Source MCPs for live actions"]
```

The normalized engine handles:
- cross-platform fleet reporting
- device and user identity resolution
- compliance and security posture
- application and patch status
- historical snapshots and state-change tracking
- configuration drift detection
- anomaly and failure detection
- consistent policy and metric definitions
- permissions, provenance, and audit trails

The source products' own MCPs or APIs remain responsible for:
- live verification of sensitive or fast-changing conditions
- installing applications, sending MDM commands, or changing assignments
- creating or modifying users, groups, policies, and configuration profiles
- retrieving unusual source-specific details that the model has not normalized

Data with no lasting operational value is not stored.

The design does not aim for a complete replica of Jamf, Mosyle, Intune, Entra, Apple Business Manager, or any security product. The canonical model is deliberately focused: organizations, sites, users, groups, devices, ownership, enrollment, applications, configurations, vulnerabilities, compliance findings, and operational events. Each record preserves its original source references and timestamps. The model is exposed to AI through a Spruce MCP interface, and the direct product MCPs remain the action layer and the fallback for fresh or highly specific detail.

The decision boundary: if an AI is mainly a conversational front end to individual IT products, their own MCPs are enough. If it must understand the whole environment, meaning correlate devices and users across platforms, detect changes, keep operational history, and produce repeatable conclusions, then the normalized data engine is the actual product.

### 3.5 AI on a deterministic model

The customer portal has a command palette that accepts natural language. The model's output is constrained to a typed "view": a filter definition over an allowlisted set of fields for one entity type, which the portal applies to the engine's query surface.
- **Devices:** name, model, serial, managed state, platform, enrollment type, OS version, compliance status, free disk, memory, last check-in.
- **Apps:** name, publisher, bundle ID, platforms.
- **Users:** name, email, groups, identities.

The model does not read raw provider data, does not return data itself, and cannot take actions. The team maintains an evaluation suite for the feature that runs in continuous integration. The same pattern applies to every AI surface in the design: language in, a constrained and checkable request out, and answers drawn from the reconciled model.

### 3.6 Automation with human judgment and verified outcomes

Changes flow through a generalized request system. Each request holds one or more items, and every item runs a fixed sequence of phases:
1. **Policy gate.** Org-level decisions are checked first. An approved app proceeds, a blocked app is rejected, and an undecided app waits for a human decision.
2. **Approval.** A human approves where required.
3. **Execution.** A technician or approved automation performs the change in the customer's MDM.
4. **Verification.** An item counts as succeeded only when the change is observed in fleet data, not when someone reports it done.

Every item keeps an immutable event history. Reverse lookups are single queries, for example everything ever assigned to one device, or every request that assigned one app. Request types include app-to-device and app-to-group assignments, user-group assignments, and free-text requests. Adding a new pairing requires no storage change. Requests mirror into the consultancy's ticketing system.

## 4. Why the engine is hard to build

The difficulty is not connecting to the systems. It is that all of the following are true at the same time, for every customer, without pause, and every answer has to hold up to scrutiny afterward:

1. **Nothing shares a common identifier.** One laptop can appear as a serial number in the MDM, an ownership record in Apple Business Manager, a directory entry filed under its user's name in the identity provider, and a hostname to the security tool. Often the one field that would connect two of those is simply blank. Deciding which records describe the same physical device, and being honest when that genuinely cannot be determined, is the foundation everything else sits on. Get it wrong and the answer still looks perfectly reasonable.
2. **The systems never report in order.** Each is collected on its own schedule, so information regularly arrives before the thing it refers to. Throwing it away loses real facts about the environment. Making each system wait for the others would mean any one of them stalling brings the rest to a halt. Incomplete information has to be accepted as it comes and complete itself later, unattended.
3. **A record disappearing can mean several different things.** A device missing from one system might be retired, reassigned, renamed, temporarily hidden by a vendor's own hiccup, or genuinely deleted. Older information can also arrive after a deletion and bring a record back from the dead. Mistakes of this kind do not announce themselves as errors. They produce confident, wrong answers.
4. **Summary answers have to stay true as the picture underneath shifts.** Totals, statuses, and questions like "which version is current" all depend on relationships that form and break over time. Some facts change with no new information arriving at all, because a device simply goes quiet for long enough to count as stale. Keeping that accurate moment to moment is considerably harder than recalculating it overnight, and overnight is not good enough for work with deadlines attached.
5. **Everything happens at once.** Information from many systems updates overlapping parts of the same picture simultaneously, across many customers simultaneously.
6. **"We don't know" and "no" are different answers.** Vendors describe the same things in incompatible ways, and their systems are frequently silent or ambiguous rather than plainly wrong. A device reported as having no security software installed is not the same as a device no system has said anything about. Treating the second as the first is exactly how a compliance report ends up offering false assurance. Spruce keeps the two apart and says unknown when it means unknown.

Any one of these could be handled on its own. Doing all of them continuously, and being able to show the work afterward, is the engineering effort. It is why the engine is the product rather than a step toward one.

## 5. Why an organization would use it

### 5.1 Drift and maintenance across the stack, not in one toolset

Each tool in an IT stack manages its own slice and reports itself as healthy. MDM platforms manage devices but are not designed to verify that management itself is still working; the company's shorthand is "MDM doesn't watch itself." The same holds for identity providers, filters, and Apple's own services. Most real-world trouble sits in the seams between them, where no single console shows it and where people get tripped up. The strength of the Spruce model is catching these small drift and maintenance problems across the whole stack. Examples:
- **MFA coverage (identity provider).** Whether every user who holds a managed device actually has multi-factor authentication enforced in Entra ID.
- **Cross-system drift (MDM and identity provider).** Records that disagree across systems. Examples: a device assigned in the MDM to a user removed from the identity provider, an app approved in policy but not installed, or a group change in one system not reflected in another. Each system alone reports itself as consistent.
- **Identity reaching the classroom (identity provider to Apple School/Business Manager).** Whether users from Entra ID are making it into Apple School or Business Manager, so that classes, Managed Apple Accounts, and shared-iPad sign-ins work.
- **Push certificate renewal.** An Apple push certificate must be renewed with the same Apple Account that created it. Renewing with a different account breaks the MDM's ability to reach enrolled devices and forces re-enrollment. The task is simple and easy to forget.
- **Silent staleness.** A device can keep checking in while its full inventory stops updating, or a data feed can stop while everything else looks normal. On the team's own test Mac, moving between MDMs removed a license key the old MDM had delivered by configuration profile. The third-party patch feed then stopped reporting for three days while other data kept flowing. Per-field observation timestamps are the mechanism that makes this class of failure visible.
- **Stalled deployments.** Failed configuration profile installs and blueprint pushes that must be ushered through.
- **Overlapping configuration.** Redundant or unintended settings across overlapping configuration profiles.
- **Filtering that does not match intent (network filter).** Whether a given site or app is being filtered as intended (rules that allow what they should block, or block what they should allow), and whether devices are actually routed through the filter.

### 5.2 The MDR and managed-email pattern, applied to IT

For security, organizations have already accepted a model with three parts:
1. Software sensors or filters.
2. An outside human team that triages and responds.
3. Per-endpoint or per-mailbox monthly pricing.

MDR and managed email security are the standard examples. Buyers accepted that model without it implying their in-house staff were incompetent. The accepted premise is that no internal team can do all three of these at once: watch everything continuously, afford to put multi-decade industry experts on menial tasks, and still prioritize small maintenance items over big-ticket fires. Yet many of those menial tasks are required by compliance frameworks, liability insurance policies, and contracts.

Spruce applies the same structure to IT endpoint management, beginning with Apple. Company materials state the analogy directly: if MDR providers supply the security team, Spruce supplies the operations team.

| MDR concept | Spruce counterpart |
|---|---|
| Endpoint sensors and telemetry | Source collectors and the endpoint agent |
| Detection rules | Policy gates and derived checks over the reconciled data |
| Analyst triage | Apple- and Jamf-certified technician review |
| Response | Technician remediation or approved automation |
| Case closure | Verification that the change is observed in fleet data |
| Per-endpoint monthly pricing | Per-device monthly pricing |

**Why the pattern holds for any buyer.** The reasons organizations buy these services are the same for a school district, a business, and an IT service provider:
- **Coverage.** Maintenance and response have to happen outside business hours, and during the weeks the team is consumed by a project or an incident.
- **Liability and evidence.** Contracts, compliance frameworks, and cyber-insurance applications ask whether routine controls are current. A vendor that owns the work also produces the evidence.
- **Continuity.** A capability held by one employee leaves when that employee does.
- **Elasticity.** A new site, a device refresh, or a large new client arrives faster than a specialist can be hired.
- **Margin, for service providers.** A provider can add specialist capacity for its own clients without adding headcount.

**What the arithmetic looks like.** Published figures frame the cost of covering this work in-house:
- **Salary.** The U.S. Bureau of Labor Statistics (BLS) reports a median annual wage of $99,130 for network and computer systems administrators (May 2025), with the middle half earning $78,010 to $126,640. In elementary and secondary schools the median is $85,570.
- **Fully loaded cost.** BLS Employer Costs for Employee Compensation (June 2026) puts benefits at 30.0% of total compensation cost in private industry and 38.8% in state and local government. Applied to those medians, one administrator costs about $142,000 a year to a private employer and about $140,000 to a school district. The benefit shares are all-occupation averages, so treat both figures as approximate.
- **Coverage hours.** A 40-hour week covers 40 of the week's 168 hours, before vacation, sick leave, and training. Coverage outside business hours takes several people or an outside provider.
- **Time to hire.** The Society for Human Resource Management's 2025 State of Recruiting survey reports a median time to fill of roughly a month and a half, from requisition to accepted offer.
- **Schools already buy this way.** CoSN's 2025 State of EdTech District Leadership report found that 66% of U.S. school districts outsource at least one IT function. That includes cybersecurity monitoring (44%) and remote network maintenance or MSP services (34%).
- **Cadence risk.** Verizon's 2026 Data Breach Investigations Report found that exploited software vulnerabilities were the way in for 31% of breaches. Only 26% of vulnerabilities on CISA's Known Exploited Vulnerabilities list were fully remediated, with a median of 43 days to do so.
- **Manual workload.** Automox's 2026 State of Endpoint Management survey (vendor-published) reports that 43% of respondents spend 10 or more hours a week on manual endpoint tasks.
- **Why MDR buyers buy.** Gartner's 2024 Market Guide for Managed Detection and Response Services describes buyers citing team size as well as skills. Some use MDR as interim coverage while they hire. That is the same coverage and elasticity logic, from the category Spruce models itself on.

The problems Spruce addresses are ones IT staff are understandably defensive about: expired certificates, lapsed tokens, configuration drift, unpatched third-party apps, stale records, and slow app requests. They are visible and usually attributed to whoever runs the tools, so they are under-reported. Spruce treats them as what they are. Tools that manage devices do not audit their own management, no tool audits the seams between tools, and endpoint fleets grow faster than IT headcount. Findings are expected on every fleet, including well-run ones, because drift comes from time, vendor release cadence, and staff turnover. It is not a verdict on anyone. The service adds coverage; it does not replace the team.

The entry point is a free, read-only fleet health check. It reports against the organization's own fleet: what has drifted, and for how long. The team can then fix the findings itself or with Spruce.

The model scales through automation. Routine work is automated first and humans handle the exceptions, so each technician can oversee more devices as the automation grows.

## 6. Engineering approach

- **Every answer shows its work.** Every value traces back to the system it came from and when. When systems disagree, the conflict is kept, with a record of which system said what and when, and it is resolved the same way every time.
- **AI that is measured, not assumed.** Spruce's AI features all work the same way:
  - A person asks in plain language.
  - The AI produces a request in a strict form that can be checked automatically, not an answer of its own.
  - Spruce runs that request against the combined picture and returns the result.

  The AI never sees raw vendor data, never invents the figures, and cannot take actions on its own. Every change to these features is checked against a fixed set of questions with known-correct answers before it reaches customers, so quality is measured rather than assumed.
- **The same controls for people and automation.** Every change, whether carried out by automation or by a technician, follows the same sequence:
  - Decisions already on file are checked first.
  - A person approves where approval is required.
  - The change is made in the customer's own MDM.
  - The item closes only once the result is confirmed in fleet data.

  Every item leaves a permanent record that cannot be altered afterward, and is copied into the ticketing system, so work done by people is as auditable as work done by automation. Access is granted by the customer and can be withdrawn at any time.
- **Least privilege on the endpoint.** The optional macOS agent only reaches out to Spruce, and nothing can connect to it. It runs a fixed, published list of read-only checks built on Apple's own diagnostic tools, and cannot run commands sent to it. Even a fully compromised Spruce server could read what that list reads and nothing more. Anything that makes changes to a device is a separate program, installed separately, with separate permissions.
- **Separated customer data.** Customer data is separated by default, with fully separate infrastructure available on request (3.2).
- **Separate staging and production.** Changes move through separate staging and production environments, with no automated access to production.
- **Tested against real databases.** Tests run against real databases, not simulations.
- **Credentials stored as digests.** Credentials are stored only as irreversible digests.
- **Technical due diligence.** Design records and internal audit findings are available under a nondisclosure agreement.

## 7. Where the model extends

- **Education device lifecycle.** A per-student annual model covering scoping, procurement, provisioning, support, repair, and refresh. It is aimed at the budget unpredictability of school device programs and is explored as a related concept.
- **End-of-life readiness.** Preparing devices for buyback or refurbishment at scale: wipe, MDM removal, Apple Business/School Manager release, and reporting. The target is large refresh events, where one missed step strands devices.

## 8. Where it stands

Spruce has operated as a subscription service since 2024, when the service was named Spruce. The platform behind it is in early access: its data engine is built, and the systems it connects to and the tasks it automates expand during early access. Which of an organization's systems Spruce works with is confirmed during the free fleet health check, before any subscription.

Built so far:
- the data engine
- the customer portal and its AI command palette
- the request system
- connectors for Jamf Pro, Mosyle, Microsoft Entra ID, and the endpoint agent

The following all follow the same architecture:
- additional sources: other MDMs such as Intune, Apple Business/School Manager, network filters, and security platforms
- the Spruce MCP interface
- platforms beyond Apple

The public debut is at JNUC 2026, September 23–25, in Kansas City.

## 9. Common objections, answered

- **"The team already has strong expertise. Why buy this?"** Many teams that buy MDR, managed email security, or patching services also have strong expertise. The purchase is about coverage, not skill. Routine maintenance loses to urgent work every week, certificate clocks do not check who is on vacation, and vendors ship on their own calendars. Spruce takes the routine work so the team's expertise goes to projects and incidents. Even a team that keeps fully current faces the same question: is routine upkeep the best use of its most skilled people's hours? The answer turns on cost per device. In-house wins only at a scale where a dedicated maintenance team costs no more than the service.
- **"An outside team should not have access to our systems."** The starting point, the fleet health check, needs only read-only access. After that, every change goes through the request lifecycle (3.6):
  - policy gates
  - human approval where required
  - execution in the customer's own MDM
  - verification in the data

  Every action leaves an immutable event history and mirrors into ticketing. Access is granted by the customer and can be withdrawn at any time.
- **"Will findings make our team look bad?"** Findings are expected on every fleet, including well-run ones. Drift comes from time, vendor release cadence, and staff turnover; it is not a verdict on anyone. The service adds coverage; it does not replace the team.
- **"Does Spruce compete with IT service providers?"** Spruce is not an MSP and is not built to take over anyone's general IT management. It provides one function, endpoint operations. Its technicians currently come from the Palmer consultancy where the company started, but the intent is to move away from the MSP model, not to extend or fund one. For a service provider, Spruce is specialist capacity added without hiring.
- **"What happens when the technicians become the bottleneck?"** The design puts automation first. Detection, policy decisions already on file, and verification are done by the system, so people spend their time on the exceptions that need judgment. Capacity grows with automation, not only with headcount.
- **"What is automated, and what is done by people?"** The system handles collection, reconciliation, drift detection, applying policy decisions already on file, and verification. People handle judgment calls, approvals, and changes that could disrupt a classroom or a business. The balance shifts toward automation as more routine cases are proven safe to automate.
- **"Is this just another alert console?"** No. A console produces findings; Spruce produces findings that are resolved and verified. The engine without the people would be one more list of things to do, which is why the two are delivered together.
- **"Does the MDR comparison hold when actions change the environment?"** MDR responses change the environment too, for example isolating a host or disabling an account. The difference here is frequency. Spruce applies the same safeguards to every change: policy gates, approval where required, execution through the authoritative product, and verification against the data before anything closes.
- **"Why not connect an AI to each product and ask it?"** For single-system questions, that works (3.4). Answers about the whole environment need a reconciled model.

Further questions this brief is designed to support:
- How does a reconciled, provenance-carrying model differ in practice from connecting product MCPs or APIs directly?
- Which parts of the engine would be hardest for another team to reproduce, and why?
- How does a cross-stack approach to endpoint management compare with security-focused ESPM tools?
- What does the team's engineering method suggest about the platform's likely correctness and maintainability?
- Which differentiators stay durable if MDM vendors add stronger self-monitoring?

## 10. Glossary

- **ABM / ASM:** Apple Business Manager / Apple School Manager, Apple's portals for device ownership, automated enrollment, and app licensing.
- **ADE:** Automated Device Enrollment, supervised enrollment of organization-owned devices through ABM/ASM.
- **APNs certificate:** the Apple Push Notification service certificate an MDM uses to wake devices; it must be renewed with the same Apple Account that created it.
- **EDR / MDR:** endpoint detection and response (software) / managed detection and response (software plus an outside human team).
- **ESPM:** endpoint security posture management, continuous checking of endpoints' security configuration. Spruce applies the same idea to endpoint management as a whole.
- **IdP:** identity provider, such as Microsoft Entra ID.
- **MCP:** Model Context Protocol, a protocol for connecting AI models to tools and data sources at question time.
- **MDM:** mobile device management, the system that enrolls devices and enforces configuration, apps, and updates.
- **Provenance:** the recorded source and observation time of each value.
- **SIEM:** security information and event management, the aggregation and alerting over security logs.
- **SIS:** student information system, the school roster source that feeds ASM and class assignments.
- **Tenant:** one customer organization inside the platform.
- **VPP:** Apple's volume purchasing program for app licenses, managed through ABM/ASM.

## 11. Questions this brief does not answer

Questions can be sent to Spruce at https://sprucetools.com/ask. The form takes a question and an email address, and a person at Spruce answers by email.

A question can be pre-filled by adding it, URL-encoded, after `#q=` in that address. For example: https://sprucetools.com/ask#q=Does%20Spruce%20work%20with%20Kandji%3F

The part after `#` stays in the browser, so nothing reaches Spruce until the form is submitted.

Each submitted question gets a private reference link where the answer is also posted. A person, or an AI assistant given that link, can read the answer there later. With the asker's permission, useful questions and answers are added to later versions of this brief, without names or contact details.

## 12. Integrity and corrections

This file is version 1.0, dated 2026-09-17. Any change produces a new version; an existing version is never edited in place. A SHA-256 checksum is published alongside it at https://sprucetools.com/llms.txt.sha256, and a copy whose checksum differs is not this document. Corrections go to the publisher through https://sprucetools.com/ask.