Security Statement

Last updated: March 27, 2026

1. Overview

Security is foundational to everything we build at Samurai Labs. Our apps handle sensitive business data — financial costs, security audit logs, content governance records, and team productivity information — and we treat the protection of that data with the seriousness it deserves.

We follow security-by-design principles throughout the development lifecycle: from schema design and query construction, to authentication flows, AI input handling, and automated test coverage. This document describes the concrete security measures in place across all Samurai Labs apps.

      TL;DR: All apps run exclusively on Atlassian Forge. Your data never
      leaves Atlassian infrastructure. We operate no external servers. All SQL uses bind
      parameters. All apps have 6,855+ automated tests with security-specific coverage.
    

2. Platform Security (Atlassian Forge)

All Samurai Labs apps are built on Atlassian Forge, Atlassian's first-party serverless app platform. Forge provides several security guarantees by design:

Sandboxed execution environment: Each app invocation runs in an isolated compute sandbox. Apps cannot access the host operating system, other apps' data, or any network endpoint not explicitly permitted by Forge's permission model.
Tenant isolation: Forge SQL and Forge KVS (our only storage mechanisms) are partitioned per Atlassian site. Data from your organisation is inaccessible to any other tenant's installation of the same app, enforced at the platform level — not just by our code.
Managed infrastructure: We do not manage, configure, or own any servers, databases, or cloud infrastructure. All underlying infrastructure is operated and secured by Atlassian, eliminating an entire class of configuration and patching risks.
Automatic security patching: The Forge runtime is patched and updated by Atlassian automatically. We do not need to apply runtime security patches — and there is no server we could forget to patch.
No network egress: Our apps do not make outbound HTTP calls to external services. All communication is between the app and Atlassian's own APIs and storage, within Atlassian infrastructure.

3. Data Security

Data protection is enforced at multiple layers:

Storage exclusively on Forge: All persistent data is stored in Forge SQL (relational) and Forge KVS (key-value). We operate no external databases, file stores, or caches outside of Atlassian's platform.
No data egress: Customer data never leaves Atlassian's infrastructure. We make no outbound API calls that transmit customer data to external services, analytics platforms, or AI providers.
SQL injection prevention: Every SQL query across all apps uses parameterized bind parameters — no query is ever constructed by string interpolation or concatenation of user-supplied input. This is enforced as a code review standard and verified by test cases.
Encryption in transit and at rest: Data transmitted between the Forge runtime and Atlassian APIs uses HTTPS/TLS. Data stored in Forge SQL and KVS is encrypted at rest by Atlassian's managed infrastructure.

4. Authentication and Authorization

Our apps rely on Atlassian's battle-tested identity and permission system:

No separate login: Users access our apps through their existing Atlassian account. We do not implement a separate authentication system, which eliminates credential management risk on our side.
Admin-only features: All administrative configuration, data export, and destructive actions require Atlassian-admin-level permissions, enforced by checking the user's Atlassian role at the resolver level before any action is taken.
License-gated access: All resolvers across all apps check for a valid, active app license before executing. GuardRail applies an additional requireActiveLicense check on all read resolvers to prevent any data access on expired or lapsed subscriptions.
Confirmation for destructive actions: All operations that delete or irreversibly modify data (bulk delete, data reset, archive operations) require an explicit user confirmation step in the UI. There are no one-click destructive actions.

5. AI Security

SmartTag for Jira and SmartTag for Confluence include AI-powered features for automatic classification and tag suggestion. We have applied specific security controls to these features:

Atlassian-hosted models only: SmartTag uses Forge LLMs, which are Atlassian-hosted language models (currently Anthropic Claude hosted within Atlassian infrastructure). No content is sent to external AI providers or third-party APIs.
Input truncation: To limit the scope of data processed by AI and reduce prompt injection risk, inputs are truncated before passing to the model: issue summaries to 500 characters, issue descriptions to 2,000 characters, and Confluence page content to 100,000 characters.
No persistent AI training on customer data: Forge LLMs do not use customer data to train or fine-tune models. Each inference call is stateless — the model has no memory of previous calls from your organisation.
No AI on sensitive data types: AI features are applied only to content explicitly designated for classification (issue text, page content). Financial data, audit logs, and IP addresses are never passed to AI models.

6. Code Security

We apply security controls at the code level across all six apps:

Control	Implementation
SQL injection prevention	All queries use `prepare().execute(binds)` bind parameters. No dynamic string construction in SQL.
JQL injection prevention	All JQL queries use the shared `escapeJql()` utility, which sanitises user input before embedding in JQL strings.
CSV formula injection prevention	All CSV exports run through `escapeCSV()`, which prefixes dangerous characters (`=`, `+`, `-`, `@`, tab, CR) to prevent spreadsheet formula injection attacks.
API route safety	All calls to Atlassian APIs (`requestJira`, `requestConfluence`) use tagged template literals (`route`) to prevent URL injection.
ReDoS protection	All user-supplied values processed by regex patterns are subject to input length limits and safe regex construction to prevent Regular Expression Denial of Service.
Input validation	User-supplied configuration values are validated against allowlists (e.g., `ALLOWED_SETTINGS_KEYS` in ServiceCost) before being persisted.
Batch safety	All batch operations (bulk inserts, bulk updates) use chunked processing with defined limits (50–200 rows per batch) to prevent resource exhaustion.
Error handling	All catch blocks forward to Sentry for observability without leaking internal stack traces to the frontend.

7. Automated Testing

Security properties are verified continuously through our automated test suite:

6,855+ total automated tests across all six apps, covering backend resolvers, data access objects, frontend components, and integration flows.
Security-specific test cases: Each app includes tests that specifically verify injection prevention, access control enforcement, license gating, and that destructive operations require appropriate permissions.
Backend and frontend coverage: All apps have separate backend (Node.js/Jest) and frontend (jsdom/Jest) test suites, ensuring both layers are independently verified.
Mocked isolation: Tests use strict mock isolation (clearMocks, resetMocks, restoreMocks) to prevent test state leakage and ensure each case is independently valid.

8. Vulnerability Reporting

We take security vulnerabilities seriously and are committed to addressing them promptly. If you discover a potential security issue in any Samurai Labs app, please report it responsibly:

Email: support@banhidy.hu with the subject line "Security Vulnerability Report"
Include: the app name, a description of the vulnerability, steps to reproduce, and your assessment of potential impact.
We will acknowledge receipt within 48 hours and aim to provide an initial assessment within 5 business days.
We ask that you do not publicly disclose the vulnerability until we have had a reasonable opportunity to investigate and release a fix (coordinated disclosure).

We do not currently operate a formal bug bounty programme, but we are genuinely grateful for responsible disclosures and will acknowledge researchers publicly (with their permission) upon resolution.

9. Compliance Readiness

While Samurai Labs itself does not hold formal certifications such as ISO 27001 or SOC 2 (our apps run on Atlassian's certified infrastructure), our apps are designed specifically to help your organisation demonstrate and maintain compliance:

GuardRail provides audit log analysis, anomaly detection, risk scoring, and pre-built compliance reporting frameworks for HIPAA, PCI DSS, SOC 2, and custom frameworks. It is designed to be the audit trail layer for organisations with formal compliance requirements.
CostLens and ServiceCost provide financial controls and cost allocation transparency supporting FinOps governance programmes.
SmartTag and PagePulse support data governance and content lifecycle management, including retention policy enforcement and content classification — relevant to information governance and data residency requirements.

All apps process data exclusively within Atlassian's Forge platform, which holds its own compliance certifications including ISO 27001, SOC 2, and others documented at atlassian.com/trust.