Skip to content

Hypothetical use case / Use cases

The policy says no. The connection still allows it.

A team introduces an internal AI assistant to summarize customer activity. The written policy prohibits sharing confidential information with unapproved providers. The assistant’s connectors do not necessarily reflect that restriction.

Discuss your needs

Scenario overview

The request makes sense. The whole path needs review.

Sales operations owns the customer records. IT manages identity and document permissions. A third party supplies the AI service, while another maintains the integration. Each team can approve part of the workflow without seeing the whole path.

Where the problem develops

An employee asks for an account summary. The integration retrieves a restricted proposal through a broadly permitted service identity and sends selected content to external processing. A supplier attachment also contains instructions the application should treat as data, not authority.

Hypothetical scenario using synthetic information. Not a client case study, observed incident or promised result.

Illustrative system / not a client architecture

One request. Several different permissions.

  1. 01Person

    Employee request

    The requester can see an account, but not every related commercial document.

  2. 02Internal systems

    CRM + documents

    Customer contacts, confidential proposals and supplier files carry different restrictions.

  3. 03Integration boundary

    Assistant + connectors

    A service identity retrieves material and may expose write actions.

  4. 04Third party

    External AI provider

    Processing, retention and permitted use require separate review.

Connections and decision points

  • Employee → assistant: establish whose permissions govern retrieval, not only who can sign in.
  • Repository → connector → provider: check sensitive fields and approved processing destinations.
  • Assistant → CRM write action: require explicit authority and meaningful approval.
A hypothetical request path. Retrieval permissions, provider approval and permission to change a record are separate decisions.

Data access and permissions

Not every piece of data has the same permission.

Identify sensitive data and each trust boundary before agreeing the assessment.

Customer information
Contacts and account notes may contain personal or confidential information.
Commercial restrictions
Proposals and supplier material can have narrower sharing permissions than the account itself.
Evidence handling
Use approved synthetic examples and restricted evidence collection during testing.

Evaluation questions

Turn an assumption into an answer.

  1. Does the connector use the requester’s rights or broader service-account permissions?
  2. Can restricted material reach an unapproved processor, log or output?
  3. Can retrieved instructions influence a tool call or bypass approval?
  4. Who approves provider changes, retention settings and exceptions?

Third-party protocols

Technical permissions and working agreements belong together.

Technical connection
Review identities, token permissions, retrieval filters, API actions and authorized negative tests.
Vendor procedure
Confirm permitted processing, subcontractor dependencies, support access and incident responsibilities with their owners.
Business approval
Name the policy owner, data owner and person authorized to accept a remaining exception.

Proposed assessment approach

Assess the path. Improve what is agreed. Revisit changes.

  1. Compare intent with access

    Translate the selected policy into questions about records, identities, processing destinations and actions.

  2. Evaluate the agreed path

    Inspect supported configurations and test authorized scenarios using synthetic information. Record behavior and testing limits.

  3. Improve and revisit

    Consider narrower permissions, retrieval restrictions or approval changes. Validate approved changes and agree future reviews when connectors or providers change.

Research and sources

Why these questions are worth asking.

These sources inform the questions. They do not document this hypothetical scenario or establish a compliance conclusion.

  • NIST AI RMF 1.0 (2023) ↗

    NIST describes a voluntary framework for incorporating risk considerations into AI design, development, use and evaluation.

    Source reviewed October 10, 2026. Summary, not a quotation.

  • OWASP LLM02:2025, Sensitive Information Disclosure ↗

    Information disclosure is a distinct AI application risk. This informs review of what connected applications can retrieve and reveal.

    Source reviewed October 10, 2026. Summary, not a quotation.

  • OWASP LLM06:2025, Excessive Agency ↗

    Unnecessary functions, permissions and autonomy can increase the consequences of unintended model behavior. This informs the approval and access questions here.

    Source reviewed October 10, 2026. Summary, not a quotation.

Related pages

Continue the conversation.

service

AI policy & control evaluation

Compare AI policy expectations with agreed permissions, configurations, and authorized behavior tests to identify enforcement gaps and practical improvements.

Explore service

Security policies & governance

Develop scoped security and AI-use policy guidance with named owners, review responsibilities, and practical implementation considerations.

Explore service

AI access & workflow controls

Scope AI access restrictions and workflow hardening around supported platforms, data paths, tool permissions, and authorized configuration changes.

Explore

Discuss your needs

A useful next step starts with your environment.

Discuss the decision, systems, and boundaries that matter. We can establish what work is appropriate before making commitments.

Discuss your needs ↗