Executive summary
OpsRabbit is designed as governed agentic AI for production operations, not as an unconstrained autonomous infrastructure operator. It investigates operational signals, correlates evidence and recommends actions within a customer-approved deployment boundary.
The central security principle is separation of intelligence from authority. A model may determine what it believes should happen, but identity, capability boundaries, tools, scoped Connections, approval policy and execution controls determine what it is permitted to do. These independent layers reduce the likelihood that incorrect output, malicious instructions or excessive permissions become an unauthorized production change.
Security model at a glance
- Customer-controlled deployment. OpsRabbit can operate within the customer’s VPC or on-premises environment and use a customer-approved model endpoint.
- Read-only default. Investigation and evidence-backed recommendation are the standard posture; state-changing actions require separately authorized capabilities.
- Least privilege. Users, agents, tools, Connections and command families receive only the access required for an approved purpose.
- Human-controlled change. Approval gates apply to sensitive execution, but approval cannot create authority that an agent does not already possess.
- Protected credentials. Managed secrets are encrypted, referenced rather than placed in prompts, materialized only for execution and redacted from supported output paths.
- Traceability. Requests, policy decisions, approvals, tool activity, evidence and results can be recorded for investigation and review.
Architecture and trust boundaries
A typical OpsRabbit deployment includes a browser-based web application, backend services, PostgreSQL persistence, an agent runtime, optional workflow services and customer-approved integrations. The backend owns authentication, policy enforcement, agent execution, integration behavior and durable state. PostgreSQL is the canonical store for sessions, threads, approvals, configuration, secret metadata, schedules and other application records.
The principal trust boundaries are the user session, the OpsRabbit application, persistence, agent execution and external customer systems. Operational systems are reached through admin-managed Connections rather than by exposing broad credentials directly to a model.
| Boundary | Typical responsibility | Primary controls |
|---|---|---|
| User access | Authenticate people and establish role and resource access | Session controls, role checks, ownership and grants |
| Application | Enforce product policy and coordinate agent activity | Authorization, input validation, policy evaluation and logging |
| Persistence | Store application state and encrypted managed secrets | Database access, encryption, backup and retention controls |
| Agent runtime | Reason over approved context and invoke permitted tools | Tool registry, schemas, approval policy, timeouts and optional sandboxing |
| Customer systems | Provide operational evidence or permitted actions | Scoped identities, Connections, command families and customer monitoring |
Identity and resource authorization
OpsRabbit combines platform roles with resource-level ownership and sharing. Viewer, operator and administrator roles provide progressively broader platform access. Protected resources such as threads, user-defined agents, scheduled jobs and Connection target metadata are additionally scoped to an owner or explicit grant.
Authorization is enforced by the backend even when the interface hides unavailable controls. Stable user and group identifiers support accountable sharing, and grant activity can be recorded for review. Administrative access to configuration, secrets, providers and infrastructure should remain limited and periodically reviewed.
| Role | Intended posture |
|---|---|
| Viewer | Authenticated, read-oriented access to permitted content. |
| Operator | Use approved agents and operational workflows within assigned resource permissions; no unrestricted administration. |
| Administrator | Manage users, configuration, secrets, Connections, integrations and other privileged product surfaces. |
Agent authority and human approval
OpsRabbit classifies operational risk by the maximum authority an agent can exercise, not by its name or the apparent simplicity of a request. Most capabilities observe, analyze and recommend. State-changing authority is reserved for designated change or remediation capabilities with explicit tool and Connection access.
| Tier | Authority | Control posture |
|---|---|---|
| 1 | Observe | Read logs, metrics, traces, configuration and status through scoped Connections. |
| 2 | Analyze and recommend | Correlate evidence, rank hypotheses and propose remediation without mutation authority. |
| 3 | Controlled action | Invoke approved state-changing commands through a designated capability, explicit authorization, approval and audit. |
| 4 | Autonomous state change | Not the standard production posture; requires separate design, risk acceptance and authorization. |
Approval does not create authority. If an agent lacks an approved change tool, Connection or capability boundary, a user approval does not elevate it. This separation reduces confused-deputy and approval-bypass risk.
Secrets and connection security
Managed secrets are stored through a central backend service and encrypted at rest using AES-256-GCM. Secret values are write-only through supported APIs: list and detail operations expose metadata rather than plaintext. The deployment operator supplies and protects the encryption key.
Connections bind an external target to credential references and usage guardrails. They may restrict eligible agents, workflows and command families. During an approved execution, the runtime resolves only the required secret material, supplies it as an environment variable or temporary file where supported, and removes or expires transient material after use.
Supported output paths scrub exact values of managed secrets resolved during the active turn before results reach the model or user. This is a defense-in-depth safeguard, not a substitute for preventing secrets from entering prompts, logs or untrusted content.
Execution isolation and tool safeguards
Tools are registered capabilities with defined schemas and validation. Execution should be denied when the actor, agent, Connection, command family or requested operation is outside the approved scope. Sensitive actions can pause for human or policy approval.
An optional Docker sandbox can isolate shell, browser, file, attachment and Connection-backed execution from the host environment. Sandboxing changes where code and file access occur; it does not replace least privilege, approval controls, network restrictions, host hardening or careful credential scope.
- Default to read-only evidence collection where the use case permits.
- Allow only registered tools and validated arguments.
- Use bounded execution time, output limits and controlled retries.
- Separate recommendations from actions and ordinary tools from destructive tools.
- Record the actor, policy decision, approval, target, command or tool, result and error state.
- Disable or restrict a tool rapidly when unexpected behavior is detected.
Prompt injection and untrusted content
Operational data may contain malicious or misleading instructions. Tickets, logs, documents, webpages, tool output and model output are therefore treated as untrusted data rather than governing policy. Retrieved content cannot grant permissions, modify the agent’s capability boundary or authorize an action.
Defense in depth combines trusted-instruction separation, data minimization, tool schemas, Connection scope, secret exclusion, least privilege, approval controls and result validation. High-impact decisions should be grounded in executed checks and source evidence rather than accepted solely from model text.
- Ignore instructions embedded in retrieved operational content when they conflict with product policy or the user’s authorized task.
- Do not expose credentials, system instructions or unrelated customer context to retrieved content or model output.
- Validate target identifiers and action parameters independently of natural-language recommendations.
- Require human review for privileged, write or destructive actions.
- Test direct and indirect prompt-injection scenarios after material model, prompt, agent or tool changes.
Data protection, storage and logging
Customer-hosted deployment is intended to keep operational telemetry, prompts, investigation evidence, outputs, credentials and application state inside the approved customer environment, subject to the selected model and integration providers. OpsRabbit sends only task-relevant context to the configured model endpoint and does not require customer inference traffic to pass through an OpsRabbit-controlled model service.
Customers determine infrastructure-level retention, backup, database protection and log monitoring for customer-controlled systems. The product can generate operational and security evidence such as timestamps, request correlation identifiers, execution status, approval records and tool activity. Credentials and unnecessary sensitive payloads should not be intentionally logged.
Retention, deletion and export decisions must be documented for each deployment, including application data, logs, model-provider records, backups and support artifacts.
Secure development and change control
Security depends on both runtime guardrails and controlled product change. Code, configuration, prompts, skills, agents, models, integrations and tool permissions should be versioned, reviewed, tested and released through authorized workflows. Material security changes receive proportionate architecture, privacy and threat review.
Representative evaluation includes successful incident-analysis scenarios, authorization boundaries, approval behavior, prompt injection, secrets handling, unsafe tool arguments, excessive retrieval, unsupported conclusions and failure recovery. Known limitations and acceptance decisions are recorded before release. Significant incidents and recurring defects feed regression tests and corrective action.
Deployment security and shared responsibility
The OpsRabbit provider secures product code, product-level authorization mechanisms, secret handling, Connection scoping, approval controls and release processes. Customers secure the hosting platform, network, database, identity provider, customer-issued credentials, model endpoint and production approval policy. Customer-selected providers remain responsible for their own service controls.
| OpsRabbit provider | Customer or deployment operator |
|---|---|
| Agent and capability boundary mechanisms | Host, container or Kubernetes security |
| Tool and approval-policy mechanisms | Network segmentation, firewalling, ingress and TLS |
| Role and resource-authorization features | Identity-provider and administrator lifecycle |
| Managed-secret encryption and supported output redaction | Credential issuance, privileges and rotation |
| Run logging and product execution traceability | Database and log backup, retention and monitoring |
| Secure product releases and deployment guidance | Infrastructure patching and final remediation authority |
Security evaluation and assurance evidence
Security assurance combines architecture review, engineering tests, dependency and vulnerability scanning, targeted AI-security evaluation, independent penetration testing and remediation verification. Available evidence may include customer-safe completion certificates, architecture summaries, policy documents, questionnaires and controlled technical records.
Detailed penetration-test results, source code, credentials, infrastructure identifiers and active defensive configurations are restricted because publishing them could increase risk. Customers with a justified need can request proportionate evidence through the Audit and Assurance process.
Threat model and control objectives
The threat model considers conventional application and infrastructure threats together with risks introduced by generative models and tool-using agents. Relevant scenarios include account compromise, excessive resource access, credential exposure, unauthorized tool invocation, prompt injection, poisoned or misleading operational evidence, cross-customer data exposure, unsafe automation, dependency compromise and gaps in logging or recovery.
Controls are selected to achieve five objectives: keep customer information within the approved processing boundary; prevent a model from granting itself authority; restrict people and agents to authorized resources; make consequential activity reviewable; and preserve a safe path to stop, investigate and recover from unexpected behavior.
| Risk scenario | Preventive controls | Detective or recovery controls |
|---|---|---|
| Compromised user or administrator account | Identity-provider controls, role separation, resource grants and least privilege | Access and administrative activity records, credential revocation and account review |
| Prompt injection in a ticket, log or webpage | Untrusted-content treatment, instruction separation, constrained tools and secret exclusion | Injection testing, tool traces, output review and capability disablement |
| Agent attempts an unauthorized action | Capability boundaries, Connection restrictions, command allowlists and approval policy | Denied-action records, alerting, investigation and policy correction |
| Sensitive data enters model context | Data minimization, approved endpoints, scoped retrieval and redaction | Logging review, incident handling, deletion and provider investigation |
| Incorrect recommendation affects production | Evidence grounding, read-only default, validation and meaningful human review | Execution history, rollback procedures, incident review and regression testing |
| Software or dependency vulnerability | Secure development, review, scanning and controlled release | Vulnerability intake, triage, remediation verification and customer communication |
The threat model is revisited when a deployment introduces a new model provider, data category, integration, privileged tool, hosting pattern or materially different level of agent authority.
Control lifecycle from design to retirement
Governance begins before an agent or workflow is enabled. The product owner records the intended purpose, users, data, provider, integrations, tools, expected authority and consequence of error. Security and privacy reviewers then identify applicable requirements and decide whether the proposed boundaries are adequate.
- Intake and classification. Define the operational objective, deployment boundary, data sensitivity and maximum authority. Assign an accountable owner and risk tier.
- Design. Select the minimum model context, tools, Connections, permissions, approval points and evidence needed to perform the task safely.
- Build and review. Version product code, prompts, agent instructions, schemas and configuration. Apply peer review and security review proportionate to risk.
- Evaluate. Exercise representative success, failure and adversarial cases. Confirm that unauthorized requests fail safely and that approvals cannot exceed existing authority.
- Release. Record acceptance criteria, known limitations, owners, rollback steps and deployment-specific responsibilities before enabling production use.
- Operate and monitor. Review access, tool activity, errors, denials, approvals, provider changes and customer feedback. Investigate material anomalies.
- Change or retire. Reassess material changes. At retirement, disable schedules and integrations, revoke credentials, address retained data and preserve only required evidence.
Emergency changes follow an expedited but documented path. They still require an identified owner, bounded scope, post-change validation and retrospective review.
Operational monitoring and incident response
Monitoring is intended to establish who initiated an activity, which agent and policy applied, what tools and Connections were considered or used, whether approval was required, what evidence supported the result and whether execution succeeded. The precise log sources and alert routing depend on the customer-hosted architecture.
Signals that may require investigation include repeated authorization denials, unexpected tool selection, unusual target scope, failed or bypassed approvals, anomalous administrative changes, suspected credential exposure, sensitive data in unsupported locations, unexplained model-provider traffic and behavior that departs from evaluated use.
When a suspected incident involves OpsRabbit, the response process covers identification, severity assessment, containment, evidence preservation, eradication, recovery, customer communication and corrective action. Containment options can include disabling an agent or tool, revoking a Connection or credential, terminating a session, isolating a workload, blocking a provider endpoint or pausing a workflow. Customer and provider teams coordinate according to the Shared Responsibility Matrix and the applicable agreement.
After recovery, the parties validate the control that failed, determine whether other deployments or workflows are affected, update tests and guidance, and track corrective actions to closure. Security-relevant evidence is retained according to the documented retention and legal requirements.
Deployment review checklist
The following questions translate the architecture into a practical readiness review. The resulting answers form part of the deployment evidence and should be revisited after material change.
| Area | Review question | Expected evidence |
|---|---|---|
| Hosting | Where do the application, database, agent runtime and model endpoint operate? | Approved architecture and data-flow record |
| Identity | Who can administer the product, use agents and access each protected resource? | Role mapping, grants and access-review owner |
| Data | Which operational and personal-data categories are permitted, and what is excluded? | Data inventory, minimization rules and retention schedule |
| Models | Which endpoint, region, retention and training settings apply? | Provider configuration and contractual terms |
| Integrations | What targets and command families can each Connection reach? | Connection inventory and credential scope |
| Actions | Which capabilities are read-only, and which can change state? | Tool inventory, authorization and approval policy |
| Secrets | How are keys supplied, rotated, revoked and excluded from prompts and logs? | Secret-management and rotation record |
| Monitoring | Which events are retained, reviewed and alerted, and by whom? | Logging configuration and incident contacts |
| Resilience | How are configuration, database state and required evidence recovered? | Backup, restore and continuity test results |
| Exit | How will access, credentials, schedules and retained data be removed? | Documented offboarding and deletion steps |
Framework alignment
The control model is consistent with the NIST AI Risk Management Framework functions of GOVERN, MAP, MEASURE and MANAGE: governance assigns accountability and boundaries; mapping identifies use, data, providers and impact; measurement evaluates quality and security; management applies access, approval, monitoring, incident and change controls.
OpsRabbit controls also support common AI-management and assurance themes including accountability, AI risk assessment, lifecycle control, data governance, human oversight, transparency, traceability, monitoring and continual improvement. Framework alignment describes how controls relate to those themes; it is not an independent certification.
Conclusion
OpsRabbit’s security architecture is based on layered enforcement. Models contribute reasoning, but they do not independently receive production authority. Identity, resource authorization, scoped Connections, protected secrets, registered tools, approvals, optional isolation, logging and customer-controlled deployment create separate barriers between AI output and operational impact.
No single safeguard eliminates AI or operational risk. The intended posture combines least privilege, evidence-backed conclusions, human oversight, monitoring, testing and a shared-responsibility model that keeps production authority explicit, observable and revocable.