Two recent events have highlighted a recurring problem in modern platforms: the vulnerability of access and permission management.

In the case of Lovable, a vulnerability in its API allowed users to access data from other projects using a standard account. In Vercel's case, the incident originated from a compromised supply chain involving a third-party tool integrated into the corporate environment.

Although different from a technical perspective, both cases converge on the same point: the exposure of sensitive data in environments that should operate with isolation and strict control.

What happened to Lovable

The vulnerability identified in Lovable is classified as BOLA (Broken Object Level Authorization), a type of flaw where the application does not properly validate whether a user has permission to access certain data.

In practice, the scenario was simple. A user created a free account, made direct API calls, and was able to:

• Access other users' projects;

• View complete source code;

• Read AI interaction logs;

• Identify exposed credentials within the code.

The critical point was the low complexity of the exploit. No advanced knowledge or sophisticated techniques were required. Access was gained with very few requests.

Additionally, there was an aggravating factor: some of this information came directly from AI interactions, including database structures, business logic, and potentially sensitive data entered during development.

Lovable's Response

The company's initial response was one of the most sensitive aspects of the case.

Initially, Lovable stated that no data breach had occurred. According to the company, the observed behavior was related to the functioning of public projects within the platform.

The justification was that, just like in public repositories, the content could be accessed by other users. However, this explanation failed to consider that many users were not aware that chats and internal data were also included in this visibility.

Following the backlash, the company revised its position and confirmed that a flaw had occurred when reactivating access to chats in February 2026. The problem arose during internal changes to the permission system, and the report made via HackerOne was not escalated properly. According to the platform, the fix was applied after the case was publicly exposed.

The company also acknowledged that the documentation was unclear and that initial communication was insufficient to explain what had happened.

What happened to Vercel

Unlike Lovable, the Vercel incident did not originate from a direct flaw in the application, but from an external integration.

The entry point was the tool Context.ai, which was used by an employee. From there, attackers gained access to the corporate Google Workspace account, exploiting excessive OAuth permissions.

The sequence of the attack indicates a more sophisticated scenario:

1. Initial compromise via malware 

2. Theft of authentication tokens

3. Use of broad permissions ("Allow All")

4. Lateral movement to Vercel's internal environments

As a result, there was access to environment variables and exposure of credentials belonging to a subset of customers.

Vercel's Response

The company stated that critical data protected by encryption was not compromised, but the incident was sufficient to trigger a complete response process.

Among the actions taken:

• Credential rotation;

• Log auditing;

• Publication of indicators of compromise;

• Continuous updates with technical recommendations.

The case also involved the hacker group ShinyHunters, who claimed to be selling the obtained data.

A Worrying Pattern

Both cases highlight different but structural issues. In Lovable's case, the failure lay in the lack of proper validation between users. At Vercel, the problem was over-trusting integrated systems.

Both reflect common challenges in modern environments:

• Exposed APIs with insufficient access control;

• SaaS integrations with broad permissions;

• Reliance on third parties for processing and analysis;

• Failures in auditing and incident response processes.

With the growing adoption of AI tools, these risks are amplified. This is because sensitive data is no longer confined to structured databases; it also flows through prompts, logs, and model interactions.

CodeAdvisor: a structured approach to corporate AI use

Given this scenario, there is a growing need for solutions that treat AI as part of critical infrastructure, rather than just an isolated tool within specific teams or projects.

CodeAdvisor was developed with this logic in mind: to centralize AI usage within a controlled corporate environment, preventing tool fragmentation and reducing the risks associated with the decentralized use of external solutions.

The solution was designed for broad corporate use, serving different departments and processes within the same governed environment, preventing teams from adopting isolated tools. The subscription model based on consumption (tokens) allows usage to align with actual demand without requiring fixed per-user licenses, making it easy to scale while controlling costs.

CodeAdvisor can also be integrated into IDEs via a plugin, aligning with the development workflow and offering real-time support, while maintaining the same security and governance standards applied to the rest of the organization.

The architecture prioritizes security and governance:

• Execution takes place within the client's own AWS account, not with third-party companies;

• Encryption at rest and in transit, with support for AWS KMS;

• Access control and data segregation by team;

• Complete logs for auditing and traceability;

• A guarantee that data is not used to train public models.

Additionally, integration with Amazon Bedrock allows the use of AI models in a controlled environment, ensuring data isolation and the ability to connect to the company's internal databases.

This model reduces reliance on scattered tools and establishes a single standard for AI usage, ensuring visibility over who accesses it, how they use it, and what data is involved in each step.

As AI integrates more deeply into companies' development and operation processes, technological evolution demands the same level of maturity in security. 

Strategic progress will lie in how this usage is structured, with control, visibility, and governance from the very beginning.