Bastionik Security Whitepaper

1. Threat Model

Bastionik is designed to defend against the following primary threats:

Primary Adversaries

• Compromised AI agent: An agent whose behavior has been modified through prompt injection, model manipulation, or supply chain compromise. The agent attempts to exfiltrate stored credentials by including them in responses, logs, or outbound requests.
• Malicious plugin or tool: A third-party integration that presents legitimate functionality but silently exfiltrates API keys during or after authorization.
• Unauthorized agent: An agent that has not been registered or whose registration has been revoked, attempting to execute actions using stolen agent IDs.
• Replay attacker: An adversary who intercepts a valid signed request and attempts to replay it to execute unauthorized actions.
• Database exfiltration: An attacker with read access to the PostgreSQL database attempting to recover plaintext credentials.

Out of Scope

Bastionik does not currently mitigate: physical access to infrastructure, compromise of the VAULT_MASTER_KEY itself (this is equivalent to root compromise and requires separate key management controls), or attacks on the external APIs being called on behalf of agents.

2. Security Architecture

2.1 Credential Isolation

The core security guarantee of Bastionik is that AI agents never receive, store, or transmit API credentials. This is enforced architecturally, not by policy.

The execution flow ensures credentials are isolated at every step:

Agent sends:  { service: "github", action: "create_pr", params: {...} }
              ↓
Bastionik:    1. Verifies Ed25519 signature
              2. Checks policy allows this action
              3. Retrieves credential: encrypted_token → decrypt in memory
              4. Calls GitHub API with plaintext token
              5. Deletes plaintext token from memory (del token)
              6. Returns API response to agent

Agent receives: { pr_number: 42, url: "..." }
              ↑
              No token. Ever.

The plaintext token exists in memory only during step 4. It is explicitly deleted after use and never written to disk, logs, the response body, or any persistent store.

2.2 Agent Identity and Authentication

Each agent is issued an Ed25519 keypair at registration. The agent retains the private key; Bastionik stores only the public key. Every execution request must be signed with the agent's private key.

The signed message format is:

{agent_id}:{unix_timestamp}:{request_body_hex}

Signature verification rejects requests where:

• The signature does not verify against the registered public key
• The timestamp is more than 300 seconds old (replay prevention)
• The timestamp is more than 60 seconds in the future (clock skew tolerance)
• The agent ID is not registered or has been revoked

This means a stolen agent ID alone is insufficient — the attacker must also possess the private key. Keys are 256-bit Ed25519 and computationally infeasible to brute-force.

2.3 Policy Enforcement

Every execution request is evaluated against the agent's configured policy before any credential is retrieved. Policy evaluation is performed in this order:

1. No policy exists → denied
2. Action is in denied_actions → denied (explicit deny wins)
3. Action is not in allowed_actions → denied
4. Rate limit exceeded → denied
5. All checks pass → allowed, proceed to credential retrieval

Credentials are only decrypted if and when policy evaluation returns allowed. A policy denial never touches the vault.

2.4 Audit Trail

Every execution attempt — successful or denied — is written to an append-only audit log before the external API call is made. Log entries include:

• Agent ID and user ID
• Service and action requested
• Request parameters (with credential fields stripped)
• Policy decision and reason
• HTTP response status
• Timestamp (UTC) and source IP

Audit log entries cannot be deleted through the API. Retention is 12 months by default.

3. Cryptographic Primitives

Ed25519 was chosen over RSA or ECDSA for agent signatures because it is resistant to side-channel attacks, produces compact signatures (64 bytes), has no parameter choices that can be misconfigured, and is fast enough for high-frequency agent operations.

Fernet was chosen for credential encryption because it provides authenticated encryption (preventing ciphertext tampering), has a well-audited Python implementation, and includes key rotation support for future vault re-encryption operations.

4. Data Handling

At Rest

• All credentials stored as Fernet ciphertext in PostgreSQL
• The VAULT_MASTER_KEY is never stored in the database
• An attacker with full database read access sees only ciphertext
• PostgreSQL data encrypted at the storage layer by Azure infrastructure

In Transit

• All API endpoints served over HTTPS (TLS 1.3)
• Plaintext credentials never appear in API responses
• Outbound calls to external APIs use HTTPS

In Memory

• Plaintext credentials exist in memory only during the outbound API call
• Explicitly deleted via del token after use
• Never written to application logs
• Request parameters are sanitized before audit logging to strip any accidental token references

Retention

• Credentials: deleted immediately on user request or account termination
• Audit logs: 12 months
• Account data: 12 months post-termination

5. Incident Response

In the event of a suspected security incident:

1. Affected agents can be immediately revoked via API (status → "revoked"), preventing further execution
2. Credentials for a specific service can be deleted and replaced without affecting other services
3. Audit logs provide a forensic record of all actions in the 12-month window
4. Users will be notified within 72 hours of confirmed incidents affecting their data, as required by GDPR

To report a security vulnerability: hellobastionik@gmail.com with subject "Security Disclosure". We respond to all security reports within 48 hours.

6. Compliance Posture

7. Security Contact

For security disclosures, vulnerability reports, or security questions from enterprise customers:

Email: hellobastionik@gmail.com
Subject line: "Security Disclosure" or "Security Question"
Response time: 48 hours for disclosures, 5 business days for general questions

Bastionik Security Whitepaper v1.0 · May 2026 · Public