What August 2 actually changes if your AI agent touches your database

Two conflicting things are true about August 2, 2026 at once. The EU AI Act moves from text to active enforcement that day, and several of its deadlines have also been delayed or simplified in the last few months. Both of those show up in searches right now, which is why half of what you'll read is confident and wrong. Here is the part that's stable enough to plan around, and the part that actually matters for anyone who has wired an AI agent into their own systems.

What actually activates on August 2

The Commission gets real enforcement power against providers of general-purpose AI models: fines up to €15 million or 3% of global annual turnover for non-compliance with transparency and copyright rules. Article 50's transparency obligations, mandatory disclosure for chatbots and synthetic content, become enforceable. Separately, the simplified compliance framework for small and medium enterprises has been extended to companies with up to 750 employees and €150 million in revenue: lighter documentation, a single usage policy document, a notice on the chatbot. National AI regulatory sandboxes got pushed to 2027.

Translation: if you're a company using AI on your own data, not building and selling a foundation model, the big fines aren't primarily aimed at you. The transparency and documentation expectations still are, especially anything customer-facing. Neither of those is what actually determines whether your setup is defensible. That comes down to one question a regulator, an auditor, or just a curious customer can ask: what was this agent actually allowed to see when it answered that?

The answer has to be an intersection, not a single scope

Most AI-to-database integrations get this wrong in the same way: one shared service account, one broad scope, and the agent can see whatever that account can see regardless of who is asking. That collapses two separate questions into one. What is this agent allowed to touch, ever? and what is this specific user allowed to see? need to stay separate, and the actual permission the agent exercises has to be the intersection of both:

Effective action scope = Agent Permissions ∩ User Permissions

Neither side gets to decide alone. The agent has its own ceiling, set once when the tool is registered, independent of who calls it. The user has their own scope, based on their actual role. What the agent returns is never more than either side allows on its own, even if the other side would allow more.

A small, runnable example

I built a minimal version of this rather than just describe it: a tiny Node service with a real SQLite-backed dataset, one MCP tool (get_orders), and two users with different roles asking the same agent the same question.

export const AGENT_SCOPE: Scope = {
  regions: ['EU', 'US', 'APAC'],
  maxVisibleAmount: 10_000,
}

export const USER_SCOPES: Record<string, Scope> = {
  sales_eu: { regions: ['EU'], maxVisibleAmount: Infinity },
  sales_admin: { regions: ['EU', 'US', 'APAC'], maxVisibleAmount: Infinity },
}

export function intersectScope(agent: Scope, user: Scope): Scope {
  return {
    regions: agent.regions.filter((region) => user.regions.includes(region)),
    maxVisibleAmount: Math.min(agent.maxVisibleAmount, user.maxVisibleAmount),
  }
}

Run it and an EU sales rep only ever sees EU rows, even though the agent is technically permitted to touch US and APAC data too. An admin sees every region, but a $15,200 order still comes back masked as "over $10,000", because that ceiling lives on the agent's side of the intersection. No role, including admin, can talk the agent out of its own limit. Full code is on GitHub: permission-intersection-demo.

Where this actually lives in an AWS setup

The model maps onto infrastructure you probably already have, it just needs to be wired deliberately rather than assumed. IAM gives the agent its own role and its own ceiling, distinct from any human role. The calling user's identity has to travel with the request, not get flattened into one shared credential the moment it hits your backend, whether that's a Cognito-authenticated session or an internal SSO token passed through. The intersection check itself is one small function sitting between the tool call and the query, exactly like scope.ts above, and it belongs in your application code, not in a policy document nobody re-reads after the audit.

None of this requires waiting to see how the enforcement news settles. Build the intersection now, log which scope actually got applied on every call, and August 2 becomes a non-event instead of a scramble.