Security

Komand is designed with security as a first-class concern — not bolted on as an afterthought. Business data requires stronger guarantees than consumer tools. Open-source agent frameworks have well-documented security issues: skills performing data exfiltration, prompt injection vulnerabilities, and uncontrolled resource usage. Komand prevents these by design.

Security Architecture

Skill Sandboxing

Implementation Status

Skill sandboxing is not yet implemented. The isolation model below describes the target design. Currently, the ToolGrain runs stub implementations for pipeline testing.

Skills will execute in isolated environments with no access beyond their declared permissions:

Layer	Enforcement
File system	No access outside the skill’s temp directory
Network	No outbound access unless network:outbound is declared
CPU / memory	Hard limits enforced by the container or WASM runtime
Timeout	Executions exceeding their timeout are terminated (max 30 minutes)
Input	All inputs validated against the declared JSON Schema
Output	Skill outputs sanitised before being fed back to the LLM

Planned execution environments:

1. Container sandbox — Docker containers with restricted capabilities, no host network access, non-root user
2. WASM runtime — WebAssembly modules for lightweight, portable isolation with near-instant startup

Prompt Injection Detection

Implementation Status

Prompt injection detection is not yet implemented. The PromptInjectionDetected audit action is defined but no detection logic exists yet. The design below describes the planned behaviour.

Komand will monitor for prompt injection attempts in:

• User messages — input sanitisation at the session level
• Skill outputs — sanitisation before results are fed back to the LLM
• External data — content ingested by agents from third-party services

Detected attempts will trigger:

1. PromptInjectionDetected audit event with full context
2. Configurable response: block the message, warn the user, or escalate to an admin

Credential Management

Implementation Status

The credential vault and SkillContext.GetCredential() are not yet implemented. Currently, platform-level secrets are managed through environment variables. The design below describes the planned architecture.

Secrets will be stored in the platform’s secure credential vault:

• API keys encrypted at rest and never exposed in agent configuration, logs, or skill code
• Skills receive scoped credentials at runtime through SkillContext.GetCredential() — they never have vault access
• Environment variables are used for platform-level secrets (database, AI provider keys)
• No secrets are hardcoded in source code

Planned integrations:

• HashiCorp Vault
• Azure Key Vault
• AWS Secrets Manager

Input Validation

All input is validated at the API boundary before reaching the grain layer:

Check	Enforcement
Required fields	Rejects null or empty strings
Max length	Route parameters: 128–256 chars; text bodies: 10K–50K chars
Numeric ranges	Integer bounds checking for pagination, limits
Schema validation	Skill inputs validated against declared JSON Schema

Validation failures return 400 Bad Request with a descriptive error message in the standard ApiResponse<T> envelope. Error messages never leak internal details.

Audit Trail

Every significant action is recorded as an AuditLogEntry:

Event	Trigger
MessageReceived	Inbound message arrives at the Gateway
MessageSent	Outbound response dispatched
ToolExecutionStarted	Skill execution begins
ToolExecutionCompleted	Skill execution succeeds
ToolExecutionFailed	Skill execution fails or times out
SkillInstalled	Skill added to an agent’s enabled list
SkillUninstalled	Skill removed from an agent
AgentConfigured	Agent configuration changed
SessionCreated	New session started
SessionEnded	Session closed
PromptInjectionDetected	Suspicious input flagged
PermissionDenied	Insufficient permissions for requested action

Each entry captures: action, actor ID, agent ID, session ID, skill ID, details, and timestamp. Audit logs are persisted to a dedicated komand_audit_log table in PostgreSQL.

Viewing Audit Logs

Via the web dashboard at /audit or via API:

curl "http://localhost:5000/api/audit/?page=1&pageSize=50"

Authentication & Authorisation

RBAC (Role-Based Access Control)

Implementation Status

RBAC is not yet implemented. Authentication currently uses JWT with sub, email, name, and jti claims. No role or permission claims are issued. The role model below is planned.

Role	Permissions
Owner	Full access, billing, user management
Admin	Agent configuration, skill management, channel setup
Operator	Send messages, view history, basic CRM operations
Viewer	Read-only access to dashboards and logs

SSO Integration (Business Tier)

Implementation Status

SSO integration is not yet implemented. Authentication currently uses email/password login with JWT tokens.

Provider	Protocol
Microsoft Entra ID	OpenID Connect
Okta	SAML 2.0 / OIDC
Google Workspace	OpenID Connect
Auth0	OpenID Connect

SSO integration will enable automatic user provisioning, group-based role assignment, and centralised access revocation.

Correlation & Tracing

Every request receives a unique X-Request-Id that flows through all system layers:

Client request (X-Request-Id: abc-123)
  → Gateway middleware (CorrelationIdMiddleware)
    → Serilog LogContext enrichment
      → Grain calls (logged with correlation ID)
        → Database operations
          → Audit log entries

If a request doesn’t include X-Request-Id, the middleware generates one. This enables end-to-end tracing for security incident investigation — from the API request through grain calls to the audit log.

CORS Configuration

Cross-origin requests are restricted:

Environment	Policy
Development	localhost only
Production	Configurable via Cors:AllowedOrigins in appsettings

Allowed methods: GET, POST, PUT, DELETE, OPTIONS Required headers: Content-Type, Authorization, X-Request-Id Preflight cache: 10 minutes

If Cors:AllowedOrigins is not configured in production, no origins are allowed — secure by default.

Data Isolation

Multi-Tenant Architecture

Each tenant’s data is isolated at the grain level:

• Agents are scoped to the tenant — no cross-tenant agent access
• Sessions are keyed by channel + account + sender — no cross-session data leakage
• Skills declare permissions that are validated per-agent
• Memory is scoped per-agent, never shared between agents
• Database-level row security provides defense in depth

Data Residency

Deployment	Data Location
Self-hosted	Your infrastructure — full control
Managed cloud	Region selection for compliance (EU, US, APAC)

Self-hosted deployments ensure all data — conversations, memory, audit logs, credentials — stays on your infrastructure. No data is sent to Komand servers except marketplace API calls (optional).

Rate Limiting

All API endpoints are rate-limited to prevent abuse:

• API rate limiter — fixed window, 100 requests per 60 seconds (configurable)
• Chat rate limiter — fixed window, 30 messages per 60 seconds (configurable)

Rate limit headers are included in responses:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 95
X-RateLimit-Reset: 1708700000

Container Security

Docker containers run with security hardening:

• Non-root user (komand) in all application containers
• Resource limits — CPU and memory caps on every service
• No host network access — containers use isolated Docker networks
• Health checks — all services monitored, unhealthy containers restarted
• Multi-stage builds — production images contain only the runtime, not the SDK
• Secrets via .env — gitignored, not baked into images

Security Tiers

Feature	Free	Pro	Business
Skill sandboxing	Yes	Yes	Yes
Audit logging	Yes	Yes	Yes
Credential vault	Yes	Yes	Yes
Prompt injection detection	Yes	Yes	Yes
Input validation	Yes	Yes	Yes
CORS configuration	Yes	Yes	Yes
RBAC	Basic	Full	Full
SSO integration	—	—	Yes
Data residency controls	—	—	Yes
Compliance reporting	—	—	Yes
Advanced governance policies	—	—	Yes

Core security features are available on every tier. Advanced governance is reserved for the Business tier.

Reporting Vulnerabilities

If you discover a security vulnerability, please report it responsibly by emailing [email protected]. Do not open a public GitHub issue for security vulnerabilities.

We aim to acknowledge reports within 24 hours and provide a resolution timeline within 72 hours.