Forge front-end calls a customer-owned Worker for drafting, validation, retrieval, and audit writes.
Security review
Your security team can verify the boundary themselves.
SecurePM is designed so Jira issue content has one path: from Atlassian to the data plane you control, then back to Jira. The vendor path is licensing only.
Review packet
Three boundaries procurement can inspect.
The homepage sells the workflow. This page gives security teams the implementation facts they need for approval.
Content routecustomer owned
Jira appintent + schema
draft path
Customer WorkerRAG, draft, audit
Customer modelWorkers AI / Bedrock
license path
securepm.devkey + counts only
Content boundary
Issue text, retrieved sources, drafts, and audit records stay in the customer's data plane.
Model boundary
Inference runs on Workers AI or a private model endpoint chosen by the customer.
License boundary
The control plane receives license key, opaque instance id, seat count, and content-free usage counts.
Rejection boundary
Unsupported custom-field values are returned with reasons and are not written to Jira.
Choose the path your reviewers can approve.
Connect front-end uses the same contract and keeps deployment aligned with on-prem Jira requirements.
Enterprise buyers can use the reference backend and offline license path when Cloudflare is not acceptable.
The product assumes issue text is sensitive.
The approved model path is configured by the customer; the data plane does not call shared chat tools.
Drafts stay reviewable. Unsupported custom-field values are rejected and never written to Jira.
The vendor receives licensing metadata only. The worker's allowlist omits securepm.dev.
What is processed where.
| Data type | Processed where | Stored | Retention | Customer controlled |
|---|---|---|---|---|
| Jira issue content | Customer path | Configurable | Customer policy | Yes |
| Prompt configuration | Customer environment | Configurable | Customer policy | Yes |
| Audit events | Customer logging destination | Customer-defined | Customer policy | Yes |
| License key | SecurePM service | Yes | Contract term | Partially |
| Opaque instance id | SecurePM service | Yes | Contract term | Partially |
| Content-free usage count | SecurePM service | Yes | Defined policy | Partially |
Review the controls before pilot approval.
Jira permissions are scoped to the app role and reviewed during deployment.
Human approval, project allowlists, field policies, and rejection reasons are visible before publish.
Retrieval should use approved sources with access checks, freshness rules, and tenant-specific policies.
Secrets isolation, update/version review, audit export, and incident contact are part of the enterprise rollout.
Ask the worker where it can send data.
Every deployment exposes an open endpoint that lists the external destinations configured for that worker. Security reviewers can run the same command during approval.
GET https://api.securepm.dev/egressfetching live...
// loading live allowlist from api.securepm.dev curl https://api.securepm.dev/egress
The deployed worker should show only model endpoints configured by its owner. It should not list securepm.dev as a content destination.
Plain answers for the first review.
No. The product is deployed to use the customer's model path, not a shared public training path.
Yes. The reference backend exists for air-gapped VPC and Jira Data Center buyers.
Licensing receives a key, opaque instance id, seat count, and content-free usage counts.
Audit rows are written in the customer-controlled data plane and can be exported to the customer's evidence workflow.
The customer controls the data plane storage and retention policy for sources, drafts, and audit rows.
Enterprise rollout maps access to existing Jira and identity controls during the architecture workshop.
Security packet
Request packetRequest the review packet.
The packet should include architecture, data flow, deployment guide, subprocessors, questionnaire answers, retention statement, vulnerability contact, and egress proof.