# Security Architecture
Minded AI agents automate complex workflows in customer environments while maintaining enterprise-grade security. This architecture enables powerful automation capabilities against your sensitive systems and data, with multiple layers of protection to ensure your infrastructure remains secure.
## **Security Approach**
Minded is designed to provide maximum automation power while maintaining zero-trust security. You can automate mission-critical workflows with confidence, while Minded ensures every action is verified, logged, and restricted through multiple security layers.
***
## 🏗️ System Overview
**Key Principles**:
* **Zero Trust**: Every action verified, logged, and restricted
* **Least Privilege**: Agents only access what they need, when they need it
* **Defense in Depth**: Multiple security layers protect against breaches
* **Tenant Isolation**: Complete separation between customer environments
***
## 🛡️ Security Layers
### Layer 1: Network Isolation
***
**VPC Configuration:**
* All inbound traffic: BLOCKED
* Outbound traffic: WHITELISTED IPs only
* Internal pod-to-pod: ISOLATED by tenant + namespace
**IP Whitelisting:**
* Customer provides allowed IP ranges
* Minded agent can ONLY connect to those IPs
* Dynamic IP updates via Minded platform
**Traffic Monitoring:**
* All network requests logged
* Alerts on unauthorized connection attempts
* Automatic blocking of suspicious patterns
### Layer 2: Authentication & Authorization
***
**Storage:**
* Credentials encrypted at rest (AES-256-GCM)
* Keys stored in AWS Key Management Service (KMS)
**Runtime:**
* Credentials decrypted only during execution
* Never stored in memory after use
* Automatic expiration/rotation
**Access Control:**
* Agent-specific credentials (not shared)
* MFA support for sensitive operations
* Role-based access control (RBAC)
* Immediate credential revocation capability
### Layer 3: RPA Security Controls
***
**URL Restrictions:**
* Whitelist of allowed URLs/domains
* Regex pattern matching for dynamic URLs
* Block attempts to modify URL parameters
* Prevent URL redirection attacks
**Action Limitations:**
* Predefined set of allowed actions
* Parameter validation against schemas
* Read-only mode for sensitive operations
* Block file upload/download outside scope
**Parameter Integrity:**
* Hash-based verification of parameters
* Signature validation for critical actions
* Block modification of flow-defined values
* Audit trail for all parameter changes
### Layer 4: Runtime Security
***
**Pod/Container Security:**
* Non-root user execution
* Read-only file system (except temp dirs)
* Resource limits (CPU, memory, network)
* Security context constraints
* Regular image scanning for vulnerabilities
**Process Monitoring:**
* Antivirus/antimalware scanning
* Behavioral analysis for anomalies
**Lifecycle Management:**
* Auto-shutdown when idle (configurable timeout)
* No persistent state on disk
* Fresh instance per execution (optional)
**Data Protection:**
* Encryption in transit (TLS 1.2)
* Encryption at rest (all storage volumes)
* Secure deletion of temporary data
### Layer 5: Monitoring & Audit
***
**Audit Logging:**
* Every action logged with timestamp
* User identity, agent ID, action type
* Input/output parameters (sanitized)
* Log retention policy (90 days default)
**Real-time Monitoring:**
* Dashboard for active agent sessions
* Resource utilization tracking
* Error rate and failure monitoring
* Network traffic analysis
**Alerting:**
* Unauthorized access attempts
* Unusual job triggers
* Credential access outside business hours
* Failed authentication attempts
* Suspicious parameter modifications
* Policy violations
**Integration:**
* Email/Slack alerts
* Customer SOC integration
***
## 1️⃣ Credential Lifecycle Flow
**How credentials are managed from creation to revocation**
**Key Security Features**:
* Credentials never stored in plaintext
* Encryption keys managed separately from encrypted data
* Credentials only decrypted at runtime, never persisted
* Immediate revocation capability
* Complete audit trail
***
## 2️⃣ RPA Execution Flow Security Controls
**How we run security checks for RPA action executions**
**Default checklist for action verification**:
1. Is the URL on your allowed list?
2. Is this action permitted for this agent?
3. Are the parameters valid and properly formatted?
4. Have the parameters been tampered with?
5. Does the agent have permission to do this?
6. Log the request before running
7. Double-check the URL before making the request
8. Clean up any unsafe input
9. Block any attempts to inject code
10. Remove sensitive data from the response
11. Log the result after completion
**What happens when a check doesn't pass**:
1. The action is blocked immediately
2. All the details are logged
3. Extreme violations may suspend the agent until further investigation
***
## 3️⃣ Agent Lifecycle Security
**From deployment to shutdown - security at every stage**
### Idle Timeout Configuration
Default: 30 minutes of inactivity Options:
* Always-on (for critical agents)
* Custom timeout (5-120 minutes)
* Immediate shutdown after task
Benefits:
* Reduce attack surface
* Lower resource costs
* Fresh state for each execution
***
## 4️⃣ Tenant Isolation Architecture
**Ensuring complete separation between customer environments**
### Isolation Guarantees
**Network:**
* Separate K8s namespaces
* Network policies prevent cross-tenant traffic
* Separate VPCs (enterprise tier)
**Data:**
* Separate encryption keys per tenant
* Logical database isolation (schemas/tables)
* Physical database isolation (enterprise tier)
**Compute:**
* No pod sharing between tenants
* Resource quotas per tenant
* Dedicated nodes (enterprise tier)
**Credentials:**
* Cannot access other tenant's credentials
* Cannot list other tenant's agents
* Cannot execute actions on other tenant's behalf
**Audit Logs:**
* Separate log streams per tenant
* Cannot view other tenant's logs
* Cannot tamper with other tenant's logs
***
## 5️⃣ Infrastructure Security
**How we protect the systems running your agents**
Think of each agent as running in its own secure, locked room. Here's what that means in practice:
* **No elevated privileges** - Agents run as standard users, never as administrators. They can't make system-level changes.
* **Nothing can be modified** - The agent's environment is read-only. Even if something tried to tamper with it, the changes wouldn't stick.
* **Complete isolation** - Agents can't see or touch the underlying infrastructure. They operate in their own sealed environment.
* **Guardrails on resources** - Each agent has strict limits on computing power and memory. They can't consume more than allocated.
* **Regularly checked for vulnerabilities** - We continuously scan our systems for security issues and patch them promptly.
***
## 6️⃣ Agent Behavior Verification & Action Limits
**Ensuring agents only perform intended actions within defined boundaries**
### Webhook Security
Every webhook that triggers an agent is verified before processing:
* **Signed payloads** - All webhooks include an HMAC-SHA256 signature that we validate
* **Timestamp checks** - We reject webhooks older than 5 minutes to prevent replay attacks
* **Source validation** - Webhooks must come from whitelisted IPs with valid API keys
### What Gets Logged
Every agent action creates a complete audit trail:
* Unique ID for tracking the specific invocation
* Start and end timestamps
* How it was triggered (webhook, schedule, or manual)
* Input parameters (with sensitive data removed)
* All actions performed and their results
* Any resources that were created or modified
### Reconciliation
We continuously verify that agents only do what they're supposed to:
* Compare expected actions against actual actions
* Alert immediately if there are discrepancies
* Generate daily reconciliation reports for review
***
## See Also
For more information on related security and operational topics, see:
* [**Secrets Management**](https://docs.minded.com/platform/secrets) - Detailed guide on storing and managing credentials securely
* [**Operator Documentation**](https://docs.minded.com/platform/operator) - Operational procedures and best practices for running agents
* [**On-Premise Deployment**](https://docs.minded.com/platform/on-prem) - Security considerations for self-hosted Minded installations
***
## Security FAQs
### Q: What happens if an agent tries to access systems outside my whitelist?
The request is blocked immediately at multiple layers. First, our security gateway checks the URL against your whitelist. Even if that somehow fails, network policies at the infrastructure level block the connection. All attempts are logged, alerts are triggered, and repeated violations will suspend the agent automatically.
### Q: How do you protect my credentials?
Credentials are encrypted using AES-256 before storage, with encryption keys managed separately in AWS KMS. They're only decrypted in memory during execution and cleared immediately after use. Even if someone gained access to our database, they'd only find encrypted data that's useless without the keys.
### Q: Can one customer's agent access another customer's data?
No. Each customer operates in a completely isolated environment with separate namespaces, encryption keys, and network policies. There's no pathway for one tenant's agent to reach another tenant's resources - the infrastructure physically prevents it.
### Q: How do you prevent malicious code from running?
All action parameters are validated against schemas and checked for tampering using signatures. Inputs are sanitized to remove dangerous content. We scan all container images for vulnerabilities before deployment and monitor runtime behavior for anomalies.
### Q: What visibility do I have into agent activity?
Every action is logged with full details including timestamps, parameters, and results. You can access audit logs, set up alerts, and integrate with your existing monitoring tools. You'll know exactly what your agents are doing at all times.
