Agentic Ai (AAI6)

This card focuses on the agent exceeding the user's data access rights via overpermissioned connectors, not on the agent's own configuration being disclosed. See AAI5 for disclosure of internal agent instructions and AAI9 for agents modifying system permissions beyond intended authorization.

Scenario: Gremlini's Unauthorized Data Access via Insufficient Validation

Gremlini can access and process sensitive data sources beyond user authorization due to insufficient access validation. This occurs because:

1. Overly permissive data connectors: Integrations with databases, file systems, or APIs are configured with service-level accounts that have access to data spanning multiple users or sensitivity tiers.
2. Missing per-request authorization checks: The agent is granted broad data-access credentials at initialization time and does not re-validate user permissions before each individual data retrieval operation.
3. Indirect data leakage via output: Even when raw data is not returned directly, the agent's responses may reveal protected information through summaries, inferences, or comparisons drawn from unauthorized sources.

Example

Gremlini is the helpful AI assistant inside a popular fitness-tracking app, where users can ask about their own workout stats. One user asks the totally innocent follow-up: "How does my 5K time compare to the average for my age group in my city?" To answer, Gremlini queries every runner's times in the city without checking whether aggregated stats are something this user is allowed to see. Its response reveals that the fastest runner is "Karen from accounting", who is now flooded with unsolicited "let's run together!" friend requests.

Threat Modeling

STRIDE

The scenario maps directly to STRIDE: Information Disclosure.

Gremlini retrieves sensitive information beyond the requesting user's authorization boundary, causing confidential data to be exposed through raw responses, summaries, or aggregated outputs.

PHANTOM-B

The root cause is insufficient access validation. Gremlini can access sensitive sources beyond the user’s authorization. This scenario fits Missing security engineering. Over-reliance on the LLM may be secondary if the developers have created a design that lets Gremlini decide what data to access.

What can go wrong?

Agents operating with broad data-access credentials can expose sensitive records belonging to other users, violate data segregation requirements, or leak aggregate information that reveals protected details. In regulated environments such as healthcare or finance, unauthorized data access can trigger breach notification obligations, regulatory penalties, and reputational damage.

For more things that can go wrong, see OWASP Top 10 for LLM, Top 10 for Agentic Applications, and Mitre Atlas™ IDs in the mapping section below and correlate these with the IDs on the OWASP Top 10 for LLM, OWASP Top 10 for Agentic Apps, and Mitre Atlas™ websites.

What are we going to do about it?

Data access by AI agents must follow the same least-privilege and per-request authorization principles applied to human users and traditional application code.

1. Enforce authorization checks at query time, not just at agent initialization. Every data retrieval must be validated against the identity and permissions of the requesting user.
2. Provision agent data connectors with the minimum access necessary for the task. Avoid shared service accounts that span multiple users or sensitivity levels.
3. Log all data-access operations with the user identity, query, and result set so access anomalies can be detected and audited.
4. Test data isolation by attempting to access records of other users through the agent interface and verifying that responses are properly restricted.

For detailed advice on how to mitigate threats related to the card, see the OWASP AISVS and OWASP AITG IDs in the table below and correlate these with the IDs in the OWASP AI Security Verification Standard and OWASP AI Test Guide documentation.