Your vendor has legitimate access. Who checks how it is used?

A company with lawful access became the route into a major data incident in Denmark. On 5 October 2026, the Danish CPR register announced unauthorised access to information about approximately 8.8 million registered people. That includes deceased people and people living abroad, rather than just current residents. According to CPR, protected names and addresses were excluded.

For a business owner, this raises an uncomfortable question about an ordinary decision: when you give a supplier access to customer records, who checks whether its activity still matches the job you hired it to do?

The answer needs three parts: a defined scope, evidence of actual use, and someone authorised to intervene.

What the Danish incident establishes

DR reported that an unusually large bill helped uncover the incident, with authorities confirming that detail to the broadcaster. Billing therefore contributed to detection. It does not establish that technical monitoring was entirely absent.

Pays ApS acknowledged the incident, according to TV2/Ritzau reporting. Other reported details need equally careful attribution. Politiken reported that at least three accounts, including an administrator account, used the password “123456”. That is a newspaper finding, not an official assessment of every security control.

The alleged attacker also said they had used an AI-assisted script. Experts consulted by the newspaper considered that account plausible. The claim does not demonstrate that AI bypassed security protections.

For a business hiring a supplier, the practical issue is whether someone will notice a sudden export of customer records and have the authority to stop it. A bill can expose exceptional consumption after activity has occurred. Businesses should decide which access patterns deserve earlier attention, without assuming that any single alert will catch every incident.

Where a limited assignment becomes broad exposure

Consider a wholly fictional example. A small business hires a CRM specialist to prepare a campaign for one segment of inactive customers. The specialist receives an account that can read every customer record and export the entire database.

The assignment is narrow. The account’s capabilities expose everyone in the database if credentials are compromised or access is misused. A confidentiality clause does not change what the software permits.

Now add an AI agent to handle follow-ups. Give it the same account and permission to send messages, and it can combine broad reading with rapid outbound action. An incorrect audience selection can become a repeated operational error.

Reading records, exporting them and contacting customers therefore need separate decisions. Our guide to AI-agent permissions, plugins and governance examines how connected tools expand what an agent can actually do. That capability review belongs before credentials are issued.

Eight checks for your next vendor access review

Use these checks to request evidence from the person responsible for access. Adapt them to the application, the assignment and the sensitivity of the records.

1. Give every actor an identity. Use named accounts for people. Give an agent a separate service identity with an accountable owner. Shared credentials make it harder to establish who performed an action or to remove one person without disrupting everyone else.

2. Require stronger authentication. Enable multifactor authentication: an additional proof beyond a password. Prefer phishing-resistant methods where supported. MFA reduces some account-takeover risks; it does not prevent a legitimate user abusing granted permissions, and a stolen authenticated session may bypass the login challenge.

3. Match permissions to the task. Specify which records an account can read and which changes it can make. Grant administrative privileges only for work that requires them, for a limited period. Ask the supplier to justify permissions that exceed the agreed assignment.

4. Set boundaries for volume and export. Agree what normal activity looks like over a defined period and where extracted data may go. Disable full-database exports when unnecessary. If the application cannot enforce a limit, record that gap and choose a compensating restriction rather than treating the limit as implemented.

5. Monitor departures from the assignment. Collect useful access and export logs where available. Look for unusually large reads, bulk downloads or activity outside an agreed window. Route alerts to someone who understands the job. Stored logs provide little immediate protection if nobody reviews the relevant signals.

6. Assign the response decision. Name the person who reviews an alert, the expected response time and whoever can suspend access. Include a backup. The vendor may investigate its own service, but your business still needs an owner who can decide whether continued access is acceptable.

7. Make access expire and revocation executable. Set a review or end date. Know which accounts, keys and sessions must be disabled when work ends. Revocation can stop further access; it cannot undo disclosure or retrieve copies already taken.

8. Ask for evidence of a drill. In an authorised test environment, check that a forbidden action is blocked, a relevant event reaches the responsible person and suspension works. Record the date, result and required fixes. A documented procedure alone does not establish that the response chain functions.

Automation needs a decision boundary

An agent changes how much work can happen between human reviews. Before it starts, decide how many records it may process, which outbound actions require approval and what happens when the requested customer segment cannot be found.

In the fictional CRM example, the agent could prepare draft messages using only the approved segment. Sending would require human approval. A request to widen the audience would trigger a separate access decision, rather than silently reusing broader privileges.

For the discussion with your IT lead, these seven security questions for agentic AI projects help establish responsibilities and validation points. Agreeing them early avoids leaving the supplier or the agent to interpret the business’s tolerance for exposure.

Start with one existing supplier

Pick a vendor that already handles sensitive records. Ask the internal owner to compare the contract with the permissions actually enabled. Then ask for an activity record and a demonstration of how access would be suspended. Missing answers give you a concrete correction list before another integration is connected.

If you are preparing a business agent, scope the initial access and approval decisions with Amplify. The purpose is to define a workable starting boundary and the decisions your business retains. This conversation is not a security audit or a substitute for specialist advice on your obligations.

Institutional and press references

• CPR, 5 October 2026 announcement: scale, access through an authorised company and qualifications about affected records.
• DR on discovery of the incident: unusually large bill and confirmation from authorities.
• Ritzau report carried by dk-ai: TV2/Politiken reporting, acknowledgement by Pays ApS and the claim about an AI-assisted script.

Manon · Amplify

Manon writes for Amplify about AI agents, business operations and the decisions required before deployment.

Senior AI Writer chez Amplify16 October 2026