Atlassian Intelligence Security: Evidence for AI Actions in SaaS

Atlassian Intelligence is inside products that already hold projects, pages, tickets, and permissions. A security review is about the exact product action: summarizing a Confluence page or answering from Jira work; a connected source adds another boundary. Each action is tied to a SaaS context, and that context determines which administrator and audit records matter for the identity and data involved.

I would ask for one real project space and one real user role during the proof of concept. A blank demo tenant tells you very little about how permission boundaries hold up when the page title contains a customer name and the issue queue is full.

TL;DR

• Atlassian Intelligence security begins with the permissions and data classifications, plus audit settings, of the Atlassian cloud products that provide the content.
• A review should map the capability and user identity, the source data and connected services, plus administrator controls and retained event evidence.
• SaaS audit records explain activity inside the Atlassian product; direct LLM API integrations need their own request-level policy and audit evidence.
• DeepInspect governs HTTP AI traffic deliberately routed between authenticated callers and LLM endpoints, which is separate from Atlassian's product controls.

Atlassian product boundary

Atlassian says Atlassian Intelligence is built into its cloud products. The security evaluation is anchored in the product where the capability is enabled. Confluence content, Jira issues, service-management records, and connected work each have their own data ownership and permissions.

Atlassian's security documentation is a record of controls and considerations for Atlassian Intelligence. Administrators should verify the current product plan, capability availability, data handling terms, and tenant controls against that documentation before enabling a use case. Product behavior and administration options change more often than procurement checklists.

The core question is simple: which content can this signed-in user cause the capability to process, and where does the resulting output appear? Answer it with a test account rather than a diagram.

Evidence for AI-assisted work

A defensible review is a separation of several records. Identity-provider logs establish the session and account context. Atlassian product audit logs establish changes and administrative activity the product records. The source content is governed by its own permissions and classification. Connected applications are governed by their own authorization and data-sharing rules.

For each approved AI capability, record these facts:

• The Atlassian product and relevant workspace context where the capability operates.
• The user or service identity that initiated the action.
• The source content made available to the capability under that identity.
• The administrator setting or policy that enabled the capability.
• The generated result and destination, plus the product audit event available for investigation.

This model avoids a common mistake. A SaaS audit event can show activity in the SaaS product. It may not carry the policy state or full prompt classification required to reconstruct a separate direct LLM API call made by an internal service. The evidence has to match the route the data took.

Connector and external data review

Connected sources are an expanded review boundary. An AI capability that can read linked tools or external knowledge repositories reaches beyond one product's data model. The enterprise should identify the connector owner and grant scope, the available data and revocation process, plus the audit record for each connection. The review should include offboarding and permission changes, because access granted during a pilot often survives longer than the pilot itself.

The boundary also matters for prompt injection. Content can contain instructions aimed at an AI system even when it appears inside an approved Jira issue or Confluence page. The concern is structural: content retrieved for a useful task can influence a model's next action. Prompt injection in production describes that path and the need to inspect the request and response traffic where a control actually receives it.

The policy response should be specific. Atlassian configuration and permission hygiene govern the SaaS product. Connector authorization governs the connected resource. A request-layer enforcement point governs an HTTP call routed through it. No single label covers all three.

The physical test is straightforward. Put one restricted page and one permitted page in a test space. Ask the selected capability to work with each one under two user roles. Record the result and review the admin and product logs before expanding access. I prefer this test to a generic "AI-ready" approval because it exposes the actual content boundary.

Direct model API boundary

Many enterprises also run internal services that call LLM APIs directly for work originating in Jira or Confluence. Other SaaS services can make the same kind of direct call. That traffic is separate from an embedded Atlassian Intelligence capability. The internal service sends the HTTP request, and the service needs a policy decision tied to the identity and data classification, plus the destination and route.

This is the post-authentication gap. A valid user session or workload credential proves who reached the application. It does not establish that the particular content may travel to the selected LLM endpoint under the policy active at that moment. The solution is an enforcement point on the route that receives the actual HTTP AI request.

My opinion is that an Atlassian AI review should include a map of every direct model integration beside the product settings. Otherwise the SaaS tenant gets a careful review while the service that exports its content receives a vague exception.

DeepInspect

DeepInspect is a stateless proxy on HTTP AI traffic routed between authenticated users or agents and LLM endpoints. It evaluates identity context, role, data classification, destination, and organizational policy before the model receives the request. Each decision produces a signed, tamper-evident audit record independent of the calling application.

Atlassian's product controls are the controls for the SaaS capability, tenant settings, and content permissions. DeepInspect applies to direct LLM API traffic an enterprise deliberately routes through its proxy. Keeping those two boundaries explicit produces a review that security teams and platform engineering can each verify. Book a technical deep dive at deepinspect.ai.