We govern AI agents.
We hold ourselves to the same standard.
This page explains how Bastion Shield is built and how we handle your data, and what to do if you find a vulnerability. No marketing copy, just the facts.
Platform security controls.
These aren't policies that live in a document. They're enforced at build time and verified continuously.
Data in transit
TLS 1.3 enforced. No unencrypted connections accepted.
Data at rest
AES-256 encryption.
Log integrity
Cryptographic chaining on all activity logs. Tamper attempts are detectable and immutable once written.
Incident response
We notify affected customers before any public disclosure, and provide a written post-incident report. We do not offer a contractual response-time SLA.
Tenant isolation
Strict logical data separation per customer. Agent data from one tenant cannot be accessed by another, enforced at the query layer, not just the API layer.
Exactly what we store. And exactly what we do not.
We believe you should know precisely what data Bastion Shield holds about your AI agents and their activity. No ambiguity. No "we may collect" language.
What we store
- Agent registration metadata (name, owner, purpose, risk tier, timestamps)
- The action: its type, the resource touched, and the human it acted on behalf of
- The verdict (allow, deny, escalate), which policy decided it, and who approved
- Permission policy definitions per agent
- Risk detection flags and anomaly alerts
- Compliance evidence packages when exported
What we do not store
- Prompts and completions. They are stripped at ingest, before anything is written or hashed
- Message content, request and response bodies, documents, attachments and transcripts. Same stripper, same moment
- Raw customer data accessed by agents. We record the access event, not the data itself
- Card numbers, emails, phone numbers, national IDs, IBANs and bearer tokens, redacted from any field that survives stripping
- Personal biometric data
Found a vulnerability?
Tell us. Please.
We take security reports seriously. If you find a vulnerability in Bastion Shield, whether our platform, website, or API, we want to know about it before it becomes a problem for our customers.
We aim to acknowledge reports quickly and will keep you updated on progress and remediation, and we credit you in any disclosure if you want that recognition. We do not currently offer contractual response-time commitments. We will not pursue legal action against researchers who follow these guidelines and report in good faith.
Please don't access, modify, or exfiltrate customer data during testing. Report to us before publishing. Give us a reasonable window to patch before public disclosure.
Report a vulnerabilityWhat to include in your report
- ›Type of vulnerability (XSS, injection, auth bypass, etc.)
- ›Steps to reproduce: specific and reproducible
- ›Potential impact and affected systems
- ›Your contact details for follow-up
- ›Whether you want public credit
What to expect
A human reads every report. We will tell you what we found, what we are doing about it, and when it is fixed. We publish no fixed response-time SLA because we are a small team and would rather not promise a clock we cannot guarantee.
Questions about our security posture?
If you're running a vendor security review, we have documentation packages available on request. We respond to security questionnaires directly, no generic PDFs.