Security and trust
TestWarden security: built on Forge, explained plainly.
TestWarden runs on Atlassian Forge: Forge-hosted, tenant-isolated, with declared scopes, server-side authorization and an append-only audit trail. This page states what the app does and does not do, which parts belong to the publicly listed Marketplace V1 and which to the developer pilot lane, and what this public website uses to deliver contact requests.
Declared scopes
Every scope, with a reason.
Marketplace V1 requests the Jira scopes its workflows need, the Atlassian personal-data reporting scope, and defines two custom scopes for its App REST API. It deliberately does not request user-profile scopes; owners are shown as initials.
- read:jira-work
- Jira project and issue discovery and metadata required for project associations, requirement links, issue pickers and coverage. Also used to read the current user’s Jira permissions for role mapping.
- write:jira-work
- Explicit, user-initiated Jira defect (Bug) creation from a failed or blocked execution step. TestWarden does not otherwise write to Jira issues.
- report:personal-data
- Lets the app report the Atlassian account IDs it stores to Atlassian’s personal-data reporting service on a weekly schedule, so that erasure and anonymisation requests can be honoured. It grants no Jira data access.
- write:warden-evidence:custom
- App-defined OAuth 2.0 (3LO) scope protecting evidence submission (POST /warden/evidence) on the Forge App REST API. Granted to an integration by a site administrator, never to end users.
- read:warden-changes:custom
- App-defined OAuth 2.0 (3LO) scope protecting read access to a Change Set and its latest decision (GET /warden/change).
Developer pilot lane (post-V1, not in the V1 listing)
The developer pilot adds two custom scopes. Like the two above, they are granted to a 3LO integration by a site administrator and are checked together with the user’s current role.
- read:warden-developer:custom
- Read-only developer operations: status, obligations, plan, evidence list and explanation (GET /developer/v1/…). Used by the PowerShell client and the MCP server.
- request:warden-verification:custom
- Request a re-run (POST /developer/v1/verification/request). It can only ask for a run that a human has separately approved, and the response never carries clearance.
Access control
App REST access, by release.
Marketplace V1 and the post-V1 developer pilot have different API authorization controls. The additional pilot controls described below are outside the V1 submission.
Marketplace V1 public release
A site administrator enables App REST APIs and grants the integration its custom OAuth 2.0 (3LO) scopes through Atlassian. The frozen V1 API relies on Atlassian’s scope checks, trusted Forge installation binding and an active-license check for evidence writes. Its API handlers do not include the pilot’s current-user Jira role checks or repository read grants. The Jira interface’s role enforcement is a separate control.
Developer pilot lane (post-V1, not in the V1 listing)
The isolated developer pilot adds the following authorization checks. These describe pilot implementation boundaries and do not establish that the complete pilot has passed live acceptance.
Who can call the App REST API
A site administrator must first opt in to App REST APIs for TestWarden in Atlassian Connected apps and grant the custom scopes to a 3LO integration. The scope is necessary but never sufficient: every call is also checked on the server against the current Jira user and role.
Reading decisions
A read needs a current Jira role of Tester or higher plus an active repository grant for that exact actor, installation and repository. The checks run again before a decision is delivered, and a revoked, expired or foreign grant releases no decision data. A missing user returns 401; a denial returns a bounded 403.
Submitting evidence
Submission requires a current site administrator holding the evidence-write scope, plus an active entitlement, rechecked immediately before ingestion. To be exact about the boundary: write authority is installation-wide. An administrator with that scope can submit evidence for any repository in the installation, because per-repository write grants are not implemented. A repository read grant never authorizes a write, import, model call or approval.
What no endpoint can do
No endpoint edits policy, grants approval or accepts a caller-selected Warden state. Tenant, actor and permission come from the Forge runtime, never from a request body or header. If the platform provides no current user, the request fails closed; there is no app-level or offline-impersonation fallback.
Architecture
What runs where, and how data is handled.
Everything in this section describes the TestWarden Jira Cloud app.
Atlassian Forge architecture
TestWarden is a Forge-native Jira Cloud app. Compute runs in the Forge Node.js runtime, the user interface is Forge Custom UI, structured data lives in Forge SQL, large immutable artifacts live in Forge Object Store and background work uses Forge Async Events. TestWarden does not operate its own separate servers for the product.
Data egress
The Marketplace V1 manifest declares no external egress, no Forge Remote and no third-party analytics, logging or external AI processors. Product data is processed and stored on Atlassian-hosted infrastructure. The post-V1 developer pilot lane adds one optional capability, AI explanation through Forge’s llm module, described under AI posture. The public website uses separate analytics and contact-form services, described below.
Authentication and authorization
Users authenticate through Jira. Server-side role enforcement maps Jira permissions to Viewer, Tester, QA Manager and QA Admin: Testers execute and link defects; Managers author tests, saved views, folders, cycles and links; archive/restore and migration are Admin-only. Unclassified write operations fail closed to Admin. Display conditions are never treated as authorization.
Tenant and data isolation
Every installation has its own data scope. The installation identity is derived exclusively from Forge runtime context, never from a value supplied by the browser, and every row carries the installation identifier as defence in depth. Cross-installation access is designed to be structurally impossible.
Data in transit and at rest
Traffic between the Jira browser session, Forge and the App REST API uses the transport security Atlassian provides for Forge apps. Storage protections are those of Forge SQL and Forge Object Store. TestWarden makes no encryption, residency or certification claims beyond what Atlassian’s current platform documentation supports.
Secrets handling
TestWarden does not store Atlassian passwords. App REST access uses OAuth 2.0 (3LO) with app-defined scopes, and TestWarden itself does not store third-party OAuth credentials. Credentials stay in the customer’s CI secret store and are never given to coding agents; token custody is the producer identity boundary.
Personal data and erasure
Atlassian account IDs appear in a defined, documented set of columns such as test owners, execution testers and audit actors. The app reports them weekly through the personal-data reporting scope. When Atlassian signals that an account was closed or erased, the app anonymises it in place, preserving the audit trail, and deletes only personal views such as saved filters.
Evidence provenance
Each verification receipt records producer type, identity, version and run, the exact repository, commit, build and environment it claims to verify, a content digest and immutable raw-report references. Exact retries are idempotent and conflicting evidence is never overwritten. Caller-supplied Warden states, approvals or progression flags are rejected.
Deterministic verification
Quality Decisions are produced by a pinned, versioned policy engine with a fixed reason-code vocabulary. No model participates in the authoritative decision, and another tool’s green status, approval or score is evidence, never clearance. Decisions are append-only and replayable from pinned material; history is never rewritten.
AI posture
Marketplace V1 ships no user-facing AI and declares no external AI processor. The developer pilot lane (not part of the V1 listing) adds optional AI explanation of a decision through the Forge llm module, with a Claude model. It is off by default and runs only when a site administrator enables it, consent is recorded and a usage budget is set. Output is validated against cited sources and fails closed. It never sets or overrides a decision, and with AI off the same facts still render deterministically. Data stays per tenant and is not pooled or used for cross-customer training. Quality Memory retrieval, Verification Intelligence analyses and a Quality Agent are in development, are not part of the submitted V1 version and are not active in production. Each would require the same administrator opt-in, consent and budget controls.
Provider integrations (in development)
The read-only collectors for AIO Tests, Xray, Zephyr Scale, TestRail and Azure DevOps are scripts that run in your own CI with credentials you hold. The Marketplace V1 app does not call those services and declares no external egress. None is live today. Any path that sends data from the app to a provider would need a manifest change, disclosure on this page and Atlassian review first.
Developer clients and agents
The pilot lane’s PowerShell client and MCP server use the developer operations with a short-lived user 3LO token supplied through the launcher environment, never in prompts or tool arguments. The MCP server exposes six typed tools and no shell, SQL, clearance or grant tool. A re-run request needs a manager role, an entitlement and a separately human-approved run, and returns REQUESTED without allowing progression.
Logging
Application logs are Forge platform logs available to the app developer for operating the product. Audit and provenance records inside the app carry Atlassian account IDs, actor type and correlation identifiers. No logs are shipped to third-party services.
This website
The public website is a separate, deliberately small system.
testwarden.me is a prerendered static site with Cloudflare Web Analytics and a server-side contact endpoint. These website services do not receive Jira app product data, verification evidence, Quality Decisions or Quality Memory.
Static site and website analytics
Pages are prerendered HTML served through Cloudflare. Cloudflare Web Analytics adds a browser beacon that sends website performance and page-usage measurements to Cloudflare. This is separate from the Jira app and receives no app product data. When configured for a deployment, Cloudflare Turnstile is loaded on the contact page for abuse prevention. See the Privacy Policy for details.
Contact endpoint
A single small service accepts contact-form submissions, validates every field server-side and applies rate limits and a honeypot. When Turnstile is configured, the service also verifies its token with Cloudflare before delivery. It transmits accepted messages through Elastic Email to our Microsoft 365 support mailbox. Submissions are not stored in a database and provider credentials never reach the browser.
Scope boundary
Elastic Email and Microsoft 365 handle website-originated contact email; Cloudflare provides website delivery, analytics and optional contact-form verification. These website services play no part in Quality Decisions, test data, evidence, Jira tenant storage or Quality Memory, and the Jira app has no network path to them.
Vulnerability reporting
Report suspected vulnerabilities in the Jira app or in this website to [email protected]. Include the affected workflow, steps to reproduce, the Jira site and app version if known, and any evidence. Please do not test against Jira sites you do not own and do not access data that is not yours.
We acknowledge security reports within one business day, Monday–Friday, and keep the reporter informed through remediation. Security reports are handled separately from general support.
Incident handling
TestWarden maintains an internal security incident response runbook covering severity classification, containment, evidence preservation, tenant-isolation investigation and post-incident review. Affected customers are notified through their Jira site administrators using the contact details available to us.
Programs and certifications
TestWarden does not currently hold SOC 2, ISO 27001, HIPAA, PCI DSS or FedRAMP certification and does not claim Atlassian certification, approval or endorsement. Any Atlassian program status (such as Runs on Atlassian) will be stated here only once it is awarded for the published production version.
See how decisions are produced on The Warden, what the product does day to day in the product overview, and which claims have been verified, and at which level, on the Proof page. Data handling for the app and this website is set out in the Privacy Policy. Security reviewers can request a walkthrough through contact.
Now available on Atlassian Marketplace
Proof before progress.
TestWarden is listed on the Atlassian Marketplace for Jira Cloud. Keep your existing test-management and CI tools, and add The Warden's independent verification layer—or use TestWarden's built-in Jira test management. Visit the Marketplace to get started; we're here if you want guided setup or migration help.