Standing credentials
Shared accounts, client secrets and broad permissions become long-lived assets that security teams must store, rotate, monitor and defend.
Governed enterprise execution
Automate privileged actions without creating a new privileged security problem.
Runseal turns enterprise requests into controlled, deterministic actions. Every action is versioned, authorised, executed through constrained identities and recorded with the evidence needed for operations, security and audit.
- Customer-tenant deployed
- Managed identities
- Evidence on every action
- Lifecycle by design
- Made in the EU
Automation often removes manual work by creating a permanent privileged attack surface.
Fragmented execution
Scripts, flows and workflows implement the same business action differently, with inconsistent controls and unclear ownership.
Missing evidence
Approvals, execution details, outcomes and lifecycle obligations are spread across systems or disappear entirely.
Runseal does not add another general-purpose automation tool. It creates a governed path for the enterprise actions that carry real operational risk.
The execution model
From request to evidence, one governed path
- 01
Request
A user or trusted system requests an approved business outcome.
- 02
Governed action contract
The action has a defined schema, permissions, risk tier, execution identity and lifecycle behaviour.
- 03
Policy and approval
Runseal validates the caller, the context and any applicable approval requirements.
- 04
Constrained execution
A deterministic worker performs only the defined action, through a managed identity with limited permissions.
- 05
Evidence and lifecycle
The result, execution context, ownership and future lifecycle obligations remain traceable.
Delegated operations
Shared tenant. Distributed responsibility. Central control.
Group companies often share one Microsoft tenant while retaining separate operational responsibilities, approval chains and ownership boundaries.
Native administrative roles rarely map cleanly to those organisational boundaries. Central IT must either perform every privileged action itself or delegate broader tenant permissions than local teams should receive.
Available today
A governed scope for each company
Runseal runs a dedicated governed scope per company in the shared tenant, each with its own catalogue, inventory, execution identities and evidence. Every company operates its own actions under least-privilege, secret-free execution, and no local team holds tenant-wide administrative roles.
On the roadmap
Delegate the action, not the privilege.
Runseal is building toward a single deployment where central IT delegates approved actions across group companies. A request would be evaluated by the caller's identity, company, assigned resources and applicable policy, then carried out by a constrained execution identity under centrally managed guardrails, still without granting the underlying Azure, Entra ID or Microsoft 365 administrative roles.
Central group governance
Action contracts · policy · approvals · execution identities
-
Company A
Approved actions
Assigned resources
-
Company B
Approved actions
Assigned resources
-
Company C
Approved actions
Assigned resources
Runseal governance boundary
- Identity
- Entity
- Action
- Target
- Approval
- Execution identity
The constrained execution identity performs the action. No local user receives a Microsoft administrative role.
Shared Microsoft tenant
The model Runseal is building toward. Cross-company delegation in a single deployment is on the roadmap. Per-company isolation is available today.
Scoped autonomy
Each company or business unit receives access only to the actions and resources assigned to it.
Central governance
The group platform team defines action contracts, risk levels, approvals, lifecycle rules and execution identities.
Privileged execution without privileged users
Local users request approved outcomes without receiving standing administrative privilege in the shared tenant.
Unified evidence
Every request records the company, requester, approver, execution identity, target resource and result.
The principle stays constant: separate the right to request an outcome from the privilege required to execute it.
A governed execution layer for enterprise actions
Governed actions
Versioned enterprise verbs with defined inputs, permissions, risk and execution behaviour.
Identity-first execution
Explicit identities for callers and workloads, with no shared application credentials as the default.
Least privilege
Each worker receives only the access its defined actions require.
Lifecycle by design
Created resources can carry ownership, review dates, expiry and a governed deprovisioning path from birth.
Deterministic evidence
Every request and result produces an operational record that can support investigation, reconciliation and audit.
Customer-tenant deployment
Runseal operates inside the Azure environment you already govern. It does not require a separate external automation control plane.
Built to complement the systems you already operate
Not a workflow canvas. Existing ITSM and workflow tools can continue to coordinate processes.
Not a CMDB. Your enterprise CMDB may remain authoritative. Runseal maintains only the operational state required to govern its own actions.
Not an observability replacement. Existing monitoring platforms continue to handle metrics, logs and health.
Not an autonomous agent. Runseal executes defined enterprise actions. It does not give an AI model unrestricted access to infrastructure APIs.
Security
Privileged automation without implicit trust
Zero Trust is not a label added to Runseal. It is expressed in who can request an action, which identity may execute it, what that identity can access and what evidence remains afterwards.
- Managed identities for Azure workloads
- Explicit Entra ID authentication for users
- Server-side authorization
- Default-deny access
- Role and ownership scoping
- No broad shared execution identity
- No missing assignment becoming accidental access
- Separation between visibility and mutation privileges
Sovereignty
Your tenant. Your identities. Your execution boundary.
Enterprise automation should not require an organisation to surrender operational control to another external platform.
Runseal is deployed into the customer's Azure tenant and operates under the customer's identity, networking, policy, logging and data-residency decisions.
Runseal gives organisations operational sovereignty over how privileged actions are authorised, executed and evidenced.
Customer-tenant deployment
Runseal operates inside the Azure environment the customer already owns and governs.
Customer-controlled identities
Users authenticate through the customer's Entra ID. Workloads execute through identities governed within the customer tenant.
Customer-controlled data
Requests, execution records and operational evidence remain subject to the customer's storage, access and retention policies.
No external automation control plane
Runseal does not require a separate third-party SaaS control plane to hold broad execution credentials for the customer environment.
Customer-defined residency
The customer selects the Azure regions, logging destinations and storage locations appropriate to its regulatory and operational requirements.
Control remains where the action takes place.
Runseal supports operational sovereignty within the customer's chosen Microsoft cloud environment. It does not claim to replace the underlying cloud provider or eliminate dependencies on Microsoft Azure.
Where Runseal starts
Starting where privileged automation is hardest to govern
Identity and enterprise application lifecycle.
- Provision an enterprise application Available
- Create an application registration Available
- Review ownership Available
- Deprovision a governed application Roadmap
- Rotate credentials Roadmap
- Update authorised permissions Roadmap
- Trigger recertification Roadmap
- Enforce expiry and lifecycle review Roadmap
The platform core is reusable. Customer-specific policies, integrations and domain actions are added without embedding one customer's operating model into the product.
Proven in production constraints
Built from real enterprise constraints
Runseal's architecture has been validated through a live enterprise automation implementation in a regulated environment. The reusable product core is deliberately separated from customer-specific integrations, processes and technical constraints.
Roadmap
The execution foundation for governed enterprise agency
AI systems can increasingly identify problems and propose actions. The harder question is how those recommendations become authorised changes in a production environment.
Runseal provides the deterministic execution foundation. The longer-term Provant roadmap from SPEX focuses on the governance layer above it. It evaluates context, policy, risk, approvals and human ownership before an action is allowed to proceed.
- Human or AI recommendation
- Provant governance
- Runseal execution
- Enterprise system
- Evidence and decision trace
Provant is a roadmap direction, not current Runseal functionality.
Start with one action that matters
Technical briefing
Confirm the target process, the security boundaries and the deployment model.
Scoped proof of value
Implement one use case with one or two governed actions inside a controlled customer environment.
Domain expansion
Add reusable actions, integrations and lifecycle policies based on demonstrated value.
Developed and owned by SPEX
Runseal is developed and owned by SPEX S.à r.l. in Luxembourg.
SPEX has spent ten years designing and operating complex automation, cloud and governance solutions for European enterprise environments. Runseal turns that experience into a reusable governed execution platform.
Built in Luxembourg · Made in the EU
Learn about SPEX
Which privileged action does your organisation need to delegate safely?
Runseal can help separate local operational autonomy from the standing privilege required to act inside the shared tenant.