Atlassian AI and Knowledge Permissions

Atlassian AI can make information easier to find, but easier discovery increases the importance of getting the underlying access model right. A system that respects an existing permission may still surface information that was shared too broadly in the first place.

The review also needs to distinguish interactive use from automation. The person asking a question, the account connecting a source, and the identity executing an automated action may not be the same. Connector behavior can differ, so one successful test should not become a universal assurance.

Data-contribution policy is a separate question. Who can retrieve information through an assistant and how a supplier may use eligible contributed data are different decisions. A complete review addresses both without using a statement about one as proof of the other.

Key Takeaways

Knowledge access needs a source-by-source and context-by-context assessment.

• Review existing sharing. Permission-aware retrieval does not automatically correct overshared content.
• Identify the effective identity. Interactive and automated paths can have different access contexts.
• Use negative tests. Confirm that restricted content is not returned through the relevant answer or action path.
• Review contribution settings separately. Preserve the applicable policy date, scope, owner, and documented choice.

Start With the Information Sources

List the sources the intended use case needs. Identify the content owner, audience, sensitivity, and existing sharing model for each. Do not assume that every available connector should be enabled simply because it can increase the amount of searchable information.

Atlassian’s AI access permissions material describes permission-aware behavior for applicable interactive Rovo use. Automation can involve the connecting user’s context, and connector-specific behavior needs separate review. The assessment should preserve those distinctions.

Begin with a narrow source set that supports a defined task. A team looking for approved operational knowledge has a different requirement from a broad search across project discussions and historical records. The source selection should follow the task and its audience.

Review existing access before expansion. If a source is available to more people than intended, an assistant may make that content easier to discover without creating the original sharing problem. The source owner should decide whether the permissions still reflect current business needs.

Atlassian AI readiness therefore includes information ownership and sharing hygiene. A product-level assurance is useful context, but the organization still needs to understand the content and permissions it is connecting.

Distinguish Interactive and Automated Contexts

For an interactive request, identify the user and the applicable source permissions. For an automated workflow, identify the effective execution or connection identity and the actions it can perform. Record the difference rather than assuming the interactive model applies everywhere.

The distinction resembles the review required for Salesforce AI data access. A requester, builder, connector account, and runtime identity can serve different roles. The actual implementation must be verified in the product and scenario being used.

Ask what happens when the initiating user lacks access to a source but the automation identity has it. The answer should come from the applicable connector and execution documentation plus an approved test, not from a generic statement about permission inheritance.

Also distinguish retrieval from action. Returning a summary and changing a record create different consequences. If automation can write or trigger another process, the assessment should define the allowed operation and any required approval separately from the information it can read.

Keep each materially different path in the review. A successful interactive test does not establish the behavior of a scheduled automation, and a test for one connector does not prove the behavior of every other source.

Build a Permission-Audit Matrix

The matrix should make the effective access path understandable to the content owner and the administrator. Use one record for each materially different source and execution context.

An illustrative test can use an approved operational document and a separate restricted document. A permitted user should receive the appropriate content, while a user without the relevant access should not obtain the restricted information through the tested path. Use controlled test content and the organization’s approved process.

For automation, repeat the assessment under the actual effective identity. Do not reuse the interactive result without checking whether the execution context differs.

Atlassian AI permissions become reviewable when the matrix identifies the source, identity, expected result, and evidence. A general “permissions tested” status is too broad to support a decision after the environment changes.

Test More Than the Presence of a Citation

A response can expose information through a summary, quoted detail, title, citation, or downstream action. The test should evaluate the actual output and behavior relevant to the use case, not only whether a source link can be opened.

Define the prohibited result before running the test. If the restricted content should not be available to the user, the acceptance condition should address whether the information appears in the answer or action path. A denied source-link click alone may not answer that question.

Test permitted behavior as well. An overly restrictive configuration can prevent the system from supporting the task it was approved to perform. The goal is appropriate access, with useful results for the intended audience and reliable restriction elsewhere.

Record the content state and permissions used in the test. If either changes later, the result may need to be revisited. A test is evidence about a defined scenario at a particular point, not a permanent guarantee for every future configuration.

When a result is unexpected, determine whether the issue comes from source sharing, connector behavior, execution context, or the test’s assumptions. Those causes require different fixes and should not be collapsed into a generic “AI permissions” problem.

Review Data Contribution as a Separate Policy Decision

Atlassian’s data contribution settings FAQ describes changes effective Aug 17, 2026. It addresses eligible customer data and organization-level settings under the applicable policy. That is a separate subject from whether a particular employee may retrieve a particular document.

Do not make a blanket claim that customer data is never used for training or improvement. Review the current policy, the relevant data categories, the organization’s applicable settings, and any scope conditions. Avoid assuming a universal default across every organization or plan.

The AI transparency material supplies additional context about model and data handling. Use it to understand the applicable product behavior, while keeping the organization’s actual settings and decisions documented separately.

Assign a policy owner who can review the available choices and their implications for the organization. Record the applicable policy version, covered products or connectors, observed setting, chosen treatment, and evidence of the decision. Do not let a configuration task stand in for a policy decision that belongs to another owner.

Atlassian AI governance is clearer when retrieval permissions and contribution policy have separate records. A pass in the permission test does not resolve the data-contribution question, and a contribution setting does not prove that source access is appropriately restricted.

Keep a Dated Settings Review

The settings review should be specific enough to survive a later product or plan change. Record the organization in scope, the applicable products, the policy effective date, the reviewer, and the evidence of the selected treatment.

This is a review checklist, not an instruction to select a particular setting. The appropriate choice depends on the organization’s requirements and the actual options available under its arrangement.

Keep evidence of changes. If a plan, connector, or product scope changes, confirm whether the prior decision still applies and whether the available controls differ. The review should not depend on someone remembering what the defaults were when the pilot began.

Avoid copying a setting from one organization to another without verification. Even within the same business, different environments can have different plans, sources, and requirements. The record should identify the environment it covers.

Connect Access Governance to Production Use

Broader AI investment and production use findings can describe market activity, but production readiness requires evidence about the actual task and access boundary. A high level of industry adoption does not establish that the organization’s knowledge sources are appropriately shared.

Define the useful outcome of the pilot and measure it alongside permission behavior. Users should be able to complete the intended task with appropriate information. Restricted cases should behave as expected. Neither quality nor access should be treated as an optional check after adoption.

The same operating discipline appears in Snowflake AI compute costs, where access determines who can initiate work and cost controls need a clear response model. Across these systems, an accountable owner should understand both the permitted activity and the consequences of expanding it.

Review failures and repeated escalations. They can reveal missing knowledge, ambiguous content ownership, overly broad sharing, or a mismatch between the selected sources and the task. The response may involve improving the information model rather than adding more sources.

A successful pilot should leave the organization with an operating record it can maintain: source owners, execution contexts, test evidence, policy decisions, and retest triggers.

Expand Only With Known Access Boundaries

Before adding a source or enabling another automated path, update the matrix. Identify the effective identity, permitted content or action, and the restricted case that will test the new boundary. Review contribution policy separately where the change affects its scope.

Retest after meaningful changes in source permissions, connector configuration, automation identity, or audience. The prior result remains useful history, but it may not establish the behavior of the new arrangement.

The strongest adoption decision is specific about what people and automation can retrieve or do. It also records how the organization has addressed data contribution under the applicable policy, without confusing that decision with access control.

That gives the business a workable basis for wider use. Knowledge becomes easier to find within an access model the organization understands, and changes can be reviewed through evidence rather than broad assurances.

A source owner can make the audit more useful by selecting a realistic restricted case, such as a controlled project record intended for a limited team. Test both an authorized user and a user outside that audience through the relevant interactive or automated path. Record what information appears in the result, not only whether a link opens. The paired test helps distinguish an access-boundary issue from missing content or an incorrectly designed test, and it provides a useful case for later regression review.

Frequently Asked Questions

These answers distinguish source permissions, automation identities, and contribution policy.

Resources

Atlassian’s AI Trust page supplies access-context information. Its data-contribution FAQ supplies the policy effective-date and settings context, while its transparency material supplies additional data-handling information. All three are linked above. The audit matrix and testing approach are editorial recommendations, not verified settings for a particular organization.