CoreLB provides AI-powered infrastructure operations. Because the Services may interact with customer production environments, security is a fundamental part of our product architecture.
Customers should control what CoreLB can see and what CoreLB can do.
1. Customer-Controlled Access
CoreLB is designed to operate using permissions configured by the customer. Customers determine:
- Which environments CoreLB can access
- Which infrastructure resources are available
- Which operations CoreLB may perform
- Which operations require approval
- When access should be enabled or revoked
Customers should grant only the permissions necessary for the intended use of the Services.
2. Least Privilege
CoreLB follows the principle of least privilege. Infrastructure integrations should be configured with the minimum permissions required for the functionality being used. Where supported, customers may configure read-only access for investigation and diagnostic workflows. Additional permissions can be introduced when customers choose to enable automated remediation or operational actions.
3. AI Guardrails
AI-generated actions are subject to controls designed to reduce unintended infrastructure changes. Depending on customer configuration, controls may include:
- Allowed operations
- Restricted operations
- Environment restrictions
- Resource restrictions
- Human approval requirements
- Permission checks
- Execution limits
- Action validation
CoreLB is designed so that AI recommendations do not automatically grant the AI additional privileges.
4. Human Approval
Customers may require explicit approval before sensitive infrastructure operations are performed. This enables organizations to establish different levels of control depending on the potential impact of an operation.
5. Credentials and Secrets
CoreLB treats infrastructure credentials and secrets as sensitive information. Our architecture is designed to minimize unnecessary access, exposure, and persistence of credentials. Where technically supported, customers may use temporary credentials, delegated identities, or their existing secrets-management infrastructure. Customers are responsible for configuring appropriate credential permissions and rotating credentials according to their organization's security requirements.
6. Encryption
Information transmitted between customers and CoreLB is protected using industry-standard encryption mechanisms. Sensitive information stored by CoreLB is protected using encryption at rest where applicable. Encryption keys and access to encrypted systems are subject to access controls.
7. Authentication and Access Control
CoreLB uses authentication and authorization mechanisms to control access to customer accounts and platform functionality. Depending on the customer's plan, available controls may include:
- Multi-factor authentication
- Role-based access control
- Single sign-on
- Session controls
- Administrative access controls
8. Audit Logging
CoreLB is designed to maintain records of significant security and infrastructure events. Audit information may include:
- User identity
- Requested operation
- AI-generated action
- Target resource
- Timestamp
- Approval information
- Execution result
Audit information helps customers investigate activity and maintain operational accountability.
9. Tenant Isolation
Customer environments and data are logically isolated from one another. CoreLB applies access controls designed to prevent unauthorized cross-customer access. We continuously evaluate our architecture and controls as the platform evolves.
10. Secure Development
CoreLB follows secure software development practices intended to identify and address security issues throughout the development lifecycle. These practices may include:
- Dependency management
- Vulnerability scanning
- Code review
- Security testing
- Infrastructure security monitoring
- Access reviews
- Security-focused testing of AI functionality
11. AI Security
Because CoreLB uses AI to interact with infrastructure, we consider AI-specific threats as part of our security model. Areas of consideration include:
- Prompt injection
- Malicious instructions
- Tool misuse
- Command injection
- Unauthorized privilege escalation
- Data exfiltration
- Cross-tenant information leakage
- Unsafe AI-generated operations
AI output is treated as untrusted input and should not independently override customer permissions or security policies.
12. Incident Response
CoreLB maintains procedures for identifying, investigating, containing, and responding to security incidents. When appropriate, we may:
- Identify and contain the incident
- Revoke affected credentials or access
- Investigate the cause and impact
- Remediate affected systems
- Notify affected customers where required
- Implement corrective measures
13. Customer Emergency Controls
Customers should maintain the ability to revoke CoreLB's access to their infrastructure. Where supported, customers may immediately disable integrations or revoke credentials without requiring access to the CoreLB platform. CoreLB is designed so that customer infrastructure remains under customer control if the CoreLB service becomes unavailable.
14. Vulnerability Disclosure
We encourage responsible disclosure of security vulnerabilities. Security researchers and customers can report potential vulnerabilities through our Responsible Disclosure page or directly to [email protected]. We ask that security researchers provide enough information to reproduce and investigate the issue.
15. Security Contact
Security questions and vulnerability reports can be sent to: [email protected]