Security at Opstral

Our approach

Opstral is an enterprise AIOps platform, and security is a foundational requirement of every design decision we make. Sentinel AI operates inside customer environments with privileged access to monitoring, ITSM, cloud, and security tooling. We treat the responsibility that comes with that access as central, not incidental.

Our security program is built on three principles: least-privilege access, complete auditability, and customer data minimisation. We collect only what is necessary to perform the work, store only what is necessary to learn and improve, and log every action so customers always know what Sentinel has done.

Compliance frameworks

Our security program is aligned to the controls and practices defined by the following industry frameworks. The platform is SOC 2 and ISO 27001 compliance ready, and current status is disclosed to prospective customers under NDA.

• SOC 2Compliance ready: controls for security, availability and confidentiality aligned to the SOC 2 trust services criteria.
• ISO 27001Compliance ready: information security management practices aligned to the ISO/IEC 27001 standard.
• HIPAAAligned to the safeguards required of business associates handling protected health information. BAA available for healthcare customers.
• MITRE ATT&CKSecurity Ops detections and SIEM integrations are mapped to MITRE ATT&CK techniques, tactics, and kill chain stages.

Current certification status, audit reports, and the security architecture document are shared with prospective enterprise customers under NDA. Contact our team to start that conversation.

Data handling

Sentinel processes your telemetry, such as events, metrics, logs, and traces, to power investigation and decision-making. Sensitive fields can be excluded or redacted before logs are sent to a model, raw payloads are not retained, and no customer data is used to train shared models.

For customers with strict data residency requirements, we offer regional deployment options (US, EU, APAC) and a private cloud or on-premises deployment model where all processing stays inside customer infrastructure.

Encryption

All customer data is encrypted both in transit and at rest:

• In transit: TLS 1.3 for all network traffic between customer environments, Sentinel, and external integrations.
• At rest: AES-256 for all stored signal metadata, audit logs, and configuration.
• Credentials: stored in a dedicated secret store with envelope encryption and least-privilege scoping. Never stored in plaintext or in source control.

Authentication and access control

Sentinel authenticates to customer systems using least-privilege service accounts scoped per integration. Supported mechanisms include:

• OAuth 2.0 for SaaS and cloud platforms that support it.
• API key vault integration with HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault.
• Role-based access control that mirrors existing customer IAM policies.
• Short-lived credentials and automated key rotation where the upstream system supports it.

Permission scopes are reviewed as part of the onboarding security review. Customers can revoke access at any time.

Governed execution: the Action Ticket

Least-privilege access answers what Sentinel can reach. The Action Ticket answers what it can change, and it is the control most security reviewers ask about first.

Sentinel never writes to a customer system directly. It observes, correlates and reasons, but it holds no write scope. Every change to a customer environment is executed by ProcBot, and ProcBot will only execute a change that is wrapped in an Action Ticket. There is no other path.

Every Action Ticket records, before anything runs:

• The Machine Operations Procedure (MOP) selected, by version. Only approved, pre-defined procedures are eligible; there is no free-form command execution.
• The target systems and blast radius: which hosts, services and dependents the change touches.
• The pre-check that must pass before execution begins.
• The post-check that determines success, and the rollback path invoked automatically if it fails.
• The evidence and reasoning that led to the decision, with citations to the signals it was drawn from.
• The identity that authorised it, whether policy or a named human.

Whether a ticket executes on its own is decided by the impact of the remediation, not by the model's confidence in its diagnosis:

• No service impact: the ticket executes under policy. Pre-check, execute, post-check, verify. If the post-check fails, rollback is automatic.
• Service impact: the ticket is raised and held. Sentinel notifies the owning team and change stakeholders with the proposed MOP, blast radius and rollback path attached, and nothing executes until a named human approves it.

Autonomy is granted per use case and per system, not globally. Customers set the threshold, can require approval for any class of action regardless of assessed impact, and can withdraw autonomy for any scope at any time without redeploying. Every Action Ticket, whether approved, executed, rejected or rolled back, is retained in the audit trail described below.

Audit trail

Every action Sentinel takes (every signal correlated, every MOP executed, every escalation made, every notification sent) is captured in an immutable audit log. The audit trail includes the agent, the action, the input state, the resulting state, and the human approver where required. Customers can export the full audit log via API at any time.

This is not a marketing feature. It is how trust in autonomous operations is built and verified, and it is how we expect to be held accountable.

Deployment options

• Managed SaaS on regional infrastructure (US, EU, APAC) with single-tenant data isolation.
• Private cloud deployed inside your AWS, Azure, or GCP account; data never leaves your perimeter.
• On-premises and air-gapped for customers with strict data sovereignty or regulatory requirements.

Vulnerability management

We follow a defined vulnerability management process covering dependency scanning, container image scanning, and periodic third-party penetration testing. Critical findings are remediated under defined SLAs. Coordinated disclosure is welcome. Report security issues to info@opstral.com.

Incident response

We maintain an incident response plan that defines roles, severity classification, customer notification timelines, and post-incident review. Customers affected by a confirmed security incident will be notified in line with our contractual and regulatory obligations.

Reporting a vulnerability

If you believe you have discovered a security vulnerability in Opstral, Sentinel AI, or our website, please disclose it responsibly to info@opstral.com. We do not pursue legal action against good-faith security researchers who follow coordinated disclosure norms.

Have a security question or need our audit reports?

Email info@opstral.com. We respond to security inquiries from enterprise prospects and customers within one business day.

VWAVES Technologies Pvt. Ltd., Indore, Madhya Pradesh, India.