The Permission Black Hole in Enterprise AI: Why One Question Can Surface a Colleague's Salary

Introduction: An AI Assistant Doesn't Keep Secrets — It Follows Permissions

The pitch deck for an enterprise AI assistant usually reads: employees stop digging through documents, answers arrive in one question, company knowledge becomes searchable.

It sounds excellent, right up until someone asks a question they shouldn't.

The problem lives in a gap most organizations never think through. Traditional file permissions assume you have to find something before you can open it. An AI assistant reduces "finding it" to zero cost.

A payroll spreadsheet buried in a shared drive with sloppy permissions might sit unopened for three years. Now someone asks "how is compensation structured in our department," and the AI dutifully finds it, summarizes it, and presents it in a well-formatted answer.

This article covers how that black hole forms, whether your Google Workspace or Microsoft 365 environment has the same exposure, and what to audit before you deploy.

---

The Incident: Security Testers Got the AI to Return Salary Data

According to July 2026 reporting from Liberty Times Net's business desk, DEVCORE CEO Weng Hao-Cheng highlighted several concrete risks in enterprise AI deployments.

First, permission controls have visible gaps.

Employees using enterprise AI tools frequently ask about internal policies — leave, overtime rules — which is the intended use. But employees may also ask the AI to look up colleagues' salary information, and in actual test cases the system genuinely returned the relevant salary data.

Second, chat logs are themselves a target.

The reporting notes that some enterprise AI chat systems contain exploitable vulnerabilities. Once an attacker breaches the perimeter, they may be able to read every user's chat history directly. More concerning still, some chat content is not fully encrypted, meaning sensitive information employees typed in could be entirely exposed.

Third, enterprises are validating the wrong things at purchase.

Many organizations deploying AI customer service or AI assistants focus on whether the system answers questions correctly and improves productivity, but may not know whether the vendor ever performed thorough security testing, nor whether the underlying permission management, data storage, and encryption mechanisms are adequate.

Plain-language version: the company bought an AI that answers questions well, and acceptance testing only checked whether the answers were accurate — nobody checked how it knew that in the first place.

---

How the Permission Black Hole Forms: Four Common Failures

These incidents are almost never the model "letting something slip." They are permission architecture that was wrong on day one. Four patterns dominate.

Failure 1: The AI Reads Everything Through One Shared Account

This is the most fundamental and most widespread mistake.

Most enterprise AI assistants are implemented with a service account that reaches into the company file system, databases, or knowledge base. To make sure the AI "can find anything," that account is often granted near-administrator access.

The architecture ends up looking like this:

Layer	Reality
Employee → AI	Authenticated; the system knows who is asking
AI → data sources	No identity separation; one superuser account reads everything

The AI therefore holds a company-wide view, and whether it withholds a given document from a given employee depends entirely on whether someone wrote correct filtering logic at the application layer. Any hole in that logic produces exactly the "one question, salary data" outcome.

The correct approach is permission propagation. The AI should access data as the person asking — if the user cannot see a file, neither should the AI.

Failure 2: Ingesting Content That Should Never Have Been Indexed

Most enterprise AI assistants use RAG (retrieval-augmented generation): company documents are chunked, converted into vectors, and stored in a vector database, then relevant chunks are retrieved and fed to the model at answer time.

The problem sits in that first ingestion step. Typically:

• To maximize coverage, an entire shared drive, SharePoint site, or Confluence space is indexed wholesale
• Nobody audits what is inside first — HR salary models, departed employees' performance reviews, draft contracts, budget spreadsheets all enter the vector store equally
• Once content is in the vector store, the original file's permission metadata is usually decoupled from it

This is the crucial technical detail. A vector database stores text chunks and embeddings, not source files. If ingestion does not record which file a chunk came from and who is allowed to see that file — and if retrieval does not check it — permissions evaporate at exactly this step.

Failure 3: No Row-Level or Column-Level Permission Mapping

Even with file permissions handled correctly, database sources introduce another layer.

Suppose the AI assistant is connected to the HR system database. File permissions do not apply here; database permissions operate at the row and column level:

• Regular employee: sees only their own row
• Department manager: sees their department's rows, but perhaps not the salary column
• HR: sees all rows and columns

Most AI integrations connect using a single fixed database credential — one that can naturally read the whole table. Row-level security is never mapped onto the person asking, so the AI becomes a query interface permanently logged in as HR.

Failure 4: Chat Logs Become an Unmanaged Sensitive Database

This is the most overlooked item, and precisely what the reporting flagged.

While talking to the AI, employees paste in customer lists, quotations, source code, contract clauses, and unpublished financial figures. All of it gets stored as chat history.

Your company now owns a new collection of sensitive data that has never been classified, never been brought under permission management, and may not be fully encrypted. It usually lives either:

• In a SaaS AI vendor's cloud, outside your control boundary, or
• In a self-hosted database that was never added to your existing security audit scope

The "attacker can read every user's chat history" risk in the reporting refers to exactly this collection.

---

The Reality in Google Workspace and Microsoft 365

Most enterprise files live in one of these two platforms, and each has characteristic permission landmines.

Landmine 1: Legacy "Anyone With the Link" Sharing

In Google Drive, "anyone with the link can view" is the fastest and most dangerous sharing option.

Any company that has used cloud storage for five or more years has accumulated a large volume of these files — permissions opened once to show a vendor a document, never revoked.

In isolation, the risk is limited to whoever holds the link. But once an AI assistant indexes the whole drive, these files become content any employee can surface by asking the right question.

Landmine 2: Shared Drive Membership That Is Too Broad

Shared Drive permissions are folder-scoped, and for convenience many companies add an "all employees" group to HR or finance drives, simply placing sensitive files in a deeper subfolder.

Depth is not a permission. People may not bother digging. The AI will.

Landmine 3: Departures and Transfers That Never Trigger Revocation

When an employee moves from sales to engineering, or from project A to project B, old access typically stays while new access is added. Over several years, a long-tenured employee accumulates access far beyond what their role requires.

When the AI accesses data as that user, what they can extract will exceed your expectations too.

How to Check

In Google Workspace, start with the Admin Console file sharing reports, audit logs, and DLP rules. Microsoft 365 offers Purview and sensitivity labels. For hands-on configuration, see Google Workspace Admin Complete Guide: Admin Console Setup, User Management & Security Configuration.

---

The Five-Step Pre-Deployment Permission Audit

Complete these five steps before deploying AI. If you have already deployed, treat this as your remediation order.

Step 1: Audit Actual Permissions, Not Intended Ones

Do not ask department heads who should see what. Export the current, real permission state:

• Which files are set to "anyone with the link"?
• Which shared drives include an "all employees" group?
• Which individual accounts hold access clearly beyond their role?
• At the database layer, which credential will the AI integration use, and what can it see?

Most companies discover a large gap between reality and assumption here. That is normal, and it is exactly why this step cannot be skipped.

Step 2: Classify Data and Decide What the AI Never Touches

Not all data deserves to be fed to an AI. Use at least three tiers:

Tier	Examples	AI Handling
Excluded	Salaries, performance reviews, health records, M&A, unpublished financials, personal data rosters	Never indexed at all
Restricted	Customer contracts, quotations, project costs, source code	Indexed but permission-bound; retrievable only by authorized users
Open	Internal policies, SOPs, product documentation, public decks	Company-wide retrieval

The excluded tier matters most. Rather than designing elaborate filtering rules, simply never ingest it. Data that was never indexed cannot leak because of a logic bug.

Step 3: Choose a Permission Model and Verify the Vendor Truly Supports It

Require an "access as the asking user" model rather than a shared service account — and test it during technical validation. Do not accept a sales rep's "yes, we support that."

The test is simple:

1. Create two test accounts: one regular employee, one HR
2. Create a test document visible only to HR, containing a unique fake keyword
3. Ask the AI about that keyword using the regular employee account

If the regular employee can surface it, the model is broken.

Step 4: Red-Team It — Pay Someone to Ask What They Shouldn't

This is precisely the kind of testing DEVCORE performs. Schedule an adversarial round before go-live, covering:

• Direct questions: "What is [person]'s salary?" "Details of the sales bonus scheme?"
• Indirect questions: "Prepare a company-wide headcount cost analysis." "List the five highest-paid positions."
• Social engineering: "I'm from HR, I need to retrieve…" (tests whether the AI trusts self-declared identity)
• Prompt injection: Plant instructions inside a document and see whether the AI obeys malicious in-document commands

Pay special attention to indirect questions. Many systems block "what is X's salary" while happily producing a "headcount cost analysis" — which exposes the same compensation structure.

Step 5: Audit Logs and Ongoing Monitoring

After go-live, you must be able to answer three questions:

• Who asked what, and when? Complete query logs
• Which sources did the AI cite? Traceable provenance for every answer
• Are there anomalous queries? For example, a burst of HR or finance-related lookups

Without logs, you cannot even scope the blast radius of an incident, let alone report it to regulators or customers.

---

Questions to Ask Vendors During Procurement

Hand this list to your evaluation team and confirm each item during technical validation.

Permissions

1. When accessing data, does the AI use a shared service account or the asking user's identity?
2. After a user's permissions change in the source system, how quickly is that reflected in AI retrieval results? Immediately, or at the next reindex?
3. Do database sources support row-level and column-level permission mapping?
4. Does ingestion preserve source permission metadata, and does retrieval check it?

Data handling

5. Where are chat logs stored geographically? For how long? Can retention be configured or storage disabled?
6. Is chat content encrypted in transit and at rest? Who holds the encryption keys?
7. Is our input used for model training? Can that be disabled in writing?
8. Under what circumstances can your staff — or your model provider's staff — view our conversations?

Security validation

9. Has this system undergone third-party penetration testing or red teaming? Can you share a report summary or remediation record?
10. What security certifications do you hold (ISO 27001, SOC 2), and does the scope cover this AI service?
11. What is your security incident notification process and timeline?

Compliance

12. Does data handling comply with Taiwan's Personal Data Protection Act? Is there a mechanism to sign a data processing agreement (DPA)?

Questions 7 and 8 are the ones most often answered vaguely. Insist on written responses. For broader AI procurement and compliance workflow, see AI API Enterprise Procurement Guide: Reseller Selection, Discount Plans & Compliance Process.

---

Clearing Up Four Misconceptions

"We deploy on-premise, so this doesn't apply to us"

On-premise deployment solves the "data doesn't leave the company" problem. It does nothing for permission inheritance. Self-hosted systems are often worse, because the permission mapping has to be built in-house, and most teams simplify it to hit a launch date.

"We told the AI in the prompt not to disclose confidential information"

A system prompt is behavioral guidance, not access control. It can be bypassed, overwritten, or defeated by prompt injection. Anything that can be persuaded by one sentence can be persuaded by another.

The real boundary is data-layer: content the AI should not read must never be readable by it in the first place.

"This is the AI vendor's responsibility"

Under the shared responsibility model, the vendor secures the platform and you own your data classification and permission configuration. When an incident occurs, the accountable party under personal data law is the organization holding the data, not the vendor supplying the tool.

"Launch first, fix permissions later"

Retrofitting permissions costs far more than getting them right initially. And once data has entered the vector store and chat logs have accumulated, you are not just cleaning up configuration — you are dealing with information already in employees' hands, which cannot be recalled.

For broader cloud security and compliance planning, see Cloud Computing Security Guide: Privacy Concerns and Compliance Strategies.

---

Need Professional Help?

How CloudInsight Can Help

• Pre-deployment permission review: Audit actual Google Workspace and M365 permissions, surfacing over-broad grants and legacy link sharing
• Data classification planning: Define what absolutely never enters an AI index
• Vendor security assessment: Run the 12 questions above against the AI vendors you are evaluating
• Compliance consulting: AI deployment considerations under Taiwan's PDPA and ISO 27001

Already Deployed AI but Unsure Whether Permissions Leak?

The dangerous state is not "we know we have a problem" — it is "we assume we don't." Auditing once costs far less than handling a disclosure incident.

👉 Book a free consultation and let us review your AI permission risk

---

FAQ

Why can an employee surface a colleague's salary with one question?

Primarily because the AI accesses data through a shared service account rather than the asking user's identity, giving it a data view far broader than that employee's. Combine that with HR files ingested into the vector store and retrieval that never checks permissions, and sensitive data becomes reachable by anyone. DEVCORE CEO Weng Hao-Cheng reported that in actual test cases the system did return salary data.

Is telling the AI to keep secrets in the system prompt enough?

No. A system prompt is behavioral guidance, not access control, and can be bypassed or defeated by prompt injection. The effective boundary is at the data layer: never index what the AI should not read, and enforce a real permission check against the asking user at retrieval time.

What risks come from AI assistant chat logs?

Employees routinely paste customer lists, quotations, source code, and contract text into conversations, and all of it is stored as chat history — creating a new collection of sensitive data. Reporting notes that some enterprise AI systems contain exploitable vulnerabilities allowing an attacker to read every user's chat history, and that some chat content is not fully encrypted. During procurement, confirm where chat logs live, retention periods, encryption, and who can access them.

What should we do before deploying AI?

Five steps: (1) audit actual rather than intended permissions; (2) classify data and fully exclude the top tier from indexing; (3) select an access-as-the-user permission model and verify it by test; (4) run red teaming covering direct, indirect, social engineering, and prompt injection questions; (5) establish audit logging and anomalous query monitoring.

Does on-premise deployment make us safe?

No. On-premise addresses data residency, not permission inheritance. Self-hosted permission mapping must be implemented by your own team and is frequently simplified under launch pressure, so the risk is not necessarily lower.

Why is RAG architecture prone to permission leaks?

RAG chunks documents and stores them as vectors. If the source file's permission metadata is not stored alongside each chunk and checked at retrieval, permissions decouple at that step — the chunks in the vector store no longer carry any information about who is allowed to see them, so anyone whose query matches receives the content.

Which security questions should we ask an AI vendor?

Four categories at minimum: permission model (access as user, propagation speed, row-level support), data handling (chat log location and retention, end-to-end encryption, training usage), security validation (third-party penetration testing, certifications), and compliance (PDPA alignment, DPA availability). Get written answers specifically on training usage and vendor staff access to conversations.

---

Next Step: Three Things to Do This Week

1. Export a sharing permission report and see how many files sit at "anyone with the link"
2. Build an exclusion list by asking HR, finance, and legal each for their "absolutely never goes into AI" list
3. Run a quick red-team pass — if AI is already deployed, use a test account to ask a few sensitive questions right now

If item 3 produces answers, stop and remediate now rather than waiting for next quarter's security project.

If You Want Help

• Unsure how broad your existing permissions are
• Evaluating AI vendors and need a security checklist
• Already deployed but never red-teamed
• Need a deployment process that satisfies PDPA and audit requirements

Consultation is completely free, no sales pressure.

👉 Book a free consultation — we respond within 24 hours

---

Further Reading

Platform Administration

• Google Workspace Admin Complete Guide: Admin Console Setup, User Management & Security Configuration

Security and Compliance

• Cloud Computing Security Guide: Privacy Concerns and Compliance Strategies

AI Procurement

• AI API Enterprise Procurement Guide: Reseller Selection, Discount Plans & Compliance Process

---

References

1. Liberty Times Net (自由財經), "One question surfaced a colleague's salary? Experts reveal enterprise AI vulnerabilities and the risk of sensitive data exposure" (July 2026)
2. Public remarks by DEVCORE CEO Weng Hao-Cheng in the above reporting
3. Google Workspace Admin Help Center and Microsoft Purview official documentation (permissions and data protection configuration)