/ How it works
Surya Control is how Surya holds the standard, not something you buy.
Surya Control is the way Surya builds, operates and holds the released standard inside Surya Endpoint and Surya Fabric. It is not a product on a price list, and it is never quoted, sold or bought on its own.
Who runs it.
Surya's operated products - Standby, Endpoint, Fabric and Foundation - are run by the Surya Agent Network: the agent takes the first response on a support request, runs the device flows, and hands what it is not permitted to finish to Surya engineers on shift.
78% of responses are AI-first. AI-first means the first response to a support request comes from the Surya Agent Network, not a person. Measured across every customer Surya operates, over the 90 days to September 2026.
Surya engineers work three shifts, 365 days a year.
Inside Surya Endpoint and Surya Fabric, the Agent Network works under Surya Control, the action model described on this page. Under Surya Standby on its own, it runs the replacement loop - issuance, returns, replenishment and the custody record - and Surya Control is not involved, because there is no tenant scope to govern.
What it is.
- The operating layer inside Surya Endpoint and Surya Fabric. Where either product is in scope, Surya Control is included in it.
- It is never a separate purchase, never sold alone, and it is not used by Surya Standby on its own.
- It is what keeps a released configuration in the state the standard describes, and what produces the evidence that it stayed there.
/ How Surya Control acts
One action model, released before it is used.
Observe
Continuous evaluation of the supported operating state. Observation changes nothing.
Operate
Routine, allowlisted, tested operations run under your standing policy. An engineer does not approve every ordinary execution.
Authorize
Consequential changes - privilege grants, destructive actions, broad policy changes - require explicit authorization from your named owner.
Stop and raise
An unknown, ambiguous or unsafe condition stops the action, preserves the evidence and raises the product exception path.
Surya engineers validate each operating class before it is released. That is why routine work does not queue behind a person, and why consequential work still does.
Where it runs.
Routine analysis of the supported operating state runs on hardware dedicated to one customer in the Surya facility in Research Triangle Park. No other customer's work runs on that hardware.
Nothing about the customer's environment trains any model.
Where a correction has to be worked out, a proposal still uses an external model service, so this is not an offline arrangement. Dedicated hardware does not mean a dedicated facility, power, staff, logging infrastructure or downstream service.
Identity, and the off switch.
The identities Surya uses live in the customer's own Microsoft 365 tenant. Their administrator can see every sign-in, audit every action and revoke the access at any time.
Surya holds no global administrator role and no delegated partner access to the tenant.
What it is not.
- Not an arbitrary privileged AI agent with open access to the environment.
- Not custom automation written for one customer. Operating classes are released, then used.
- Not a response-time commitment on its own. Response commitments for your scope are set in your written proposal.
Security reviewers who need the control detail should read the security page.
/ Contribution to both outcomes
Resilience
Surya Control keeps the Endpoint and Fabric scope at its approved state, so supported recovery returns to a known configuration.
Security
It applies routine controls under standing policy and raises consequential or unknown actions for authorization, recording what it did.
Surya Control operates inside Surya Endpoint and Surya Fabric. It is not a separate purchase and is not included in Standby alone.
The common evidence and Vanta reporting workflow →