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:
Is the URL on your allowed list?
Is this action permitted for this agent?
Are the parameters valid and properly formatted?
Have the parameters been tampered with?
Does the agent have permission to do this?
Log the request before running
Double-check the URL before making the request
Clean up any unsafe input
Block any attempts to inject code
Remove sensitive data from the response
Log the result after completion
What happens when a check doesn't pass:
The action is blocked immediately
All the details are logged
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 - Detailed guide on storing and managing credentials securely
Operator Documentation - Operational procedures and best practices for running agents
On-Premise Deployment - Security considerations for self-hosted Minded installations
Browser Task (RPA) - Technical details on RPA capabilities and configurations
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.
Last updated