EU AI Act and your dev secretsWhat applies. What does not. What to do.

The EU AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024. The prohibitions in Article 5 took effect on 2 February 2025. Obligations for general-purpose AI model providers (Article 51 and above) kicked in on 2 August 2025. High-risk system obligations for most categories land on 2 August 2026.

If you run an engineering team that uses coding agents, Claude Code, GitHub Copilot, Cursor, or similar tools in your development workflow, you have been inside the Act's scope since August 2024. The question is which obligations actually apply to you, and what they require in practice.

The answer is more manageable than the compliance industry press would suggest, and it does touch your secrets stack in one specific place.

The short version

• Engineering teams using AI coding tools are deployers under Art 3(4), not providers. Different rulebook.
• Article 26 (deployer obligations) requires documented instructions, human oversight, and log retention for the AI system's outputs. It does not require you to audit Anthropic's training data.
• GDPR Art 32 still applies to anything the agent processes. If the agent reads personal data from a database during a session, you need lawful basis, data minimization, and appropriate security measures.
• The Act says almost nothing specific about runtime secrets. GDPR does, indirectly.
• Four things cover the compliance surface for most teams: document your AI tools, retain agent session logs, run a DPIA if agents handle personal data, and demonstrate least-privilege access to secrets.

Are you a provider or a deployer?

This is the first question to answer because it determines which articles govern you.

Art 3(3) defines a provider as an entity that develops an AI system and places it on the market or puts it into service, including for own use. Art 3(4) defines a deployer as a natural or legal person using an AI system under its own authority.

If your team uses Claude Code or Copilot in your development workflow, you are deploying an AI system that Anthropic or Microsoft placed on the market. You are a deployer.

If your team is building an AI product, training models, or packaging an AI-powered tool for other companies to use, you may be a provider. That is a different set of obligations, covered by Art 9 through Art 25, and outside the scope of this guide.

General-purpose AI models like GPT-4 or Claude are governed by Art 51-55 (the GPAI chapter), with those obligations placed on the model's developer, not on you as the downstream deployer. As of August 2025, Anthropic, OpenAI, Google, and others publishing large-scale GPAI models must maintain technical documentation, cooperate with authorities, and publish model cards. You benefit from this downstream; you are not responsible for it.

One wrinkle: if you use a GPAI model with "systemic risk" (Art 51(2)), the model developer has additional incident reporting and security evaluation obligations. Again, not your burden directly, but worth knowing which models your team uses and whether the provider has published the required documentation.

Articles that touch dev secrets

Article 26: deployer obligations

Art 26 is the primary article for engineering teams. It requires deployers of high-risk AI systems to:

• Use the AI system according to the provider's instructions (Art 26(1))
• Assign human oversight to competent persons and give them authority to intervene (Art 26(2))
• Monitor the AI system's operation and report serious incidents to providers (Art 26(5))
• Implement data governance relevant to the AI system's use (Art 26(4), for systems that process personal data)

A practical reading for dev teams: document that you have read and follow Anthropic's or Microsoft's usage policies, assign someone to review agent outputs before they go to production, and keep logs of agent sessions for a defined retention period.

The Act does not define specific log retention periods for deployers. Art 26(6) requires fundamental rights impact assessments in certain public-sector use cases. For private engineering teams, the baseline is reasonable retention consistent with your incident response needs. Ninety days is a common internal benchmark.

Article 50: transparency obligations

Art 50 requires parties to notify natural persons when they are interacting with an AI system, unless this is obvious from context.

For internal dev tooling, the "obvious from context" carve-out applies. Your developers know they are using Claude Code. This article creates no material obligation for internal-facing engineering tools.

It matters more if your AI agent interacts with external users, like a customer-facing support bot. That is outside the scope of this guide.

Article 64: GPAI model documentation for competent authorities

Art 64 gives competent authorities access to documentation maintained by GPAI model providers. This creates indirect benefit for you: if a regulator questions your use of a GPAI model in a workflow that processes personal data, the provider's Art 51-55 documentation is your supporting evidence that the model itself meets baseline requirements.

Keep a record of which GPAI models you use and the provider's published documentation or model cards. This is low-effort and creates a defensible paper trail.

The GDPR-AI Act interplay

The AI Act does not replace GDPR. For personal data, GDPR controls.

If your coding agent processes personal data during a session (reads a database that contains customer records, indexes a codebase with user PII embedded in logs, or summarizes support tickets), GDPR Art 32 applies. Art 32 requires "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk. The recitals name pseudonymisation, encryption, availability, and confidentiality as relevant considerations.

This is where secrets management lands. Giving an agent full database access to a production system containing personal data, when the agent only needs read access to one schema for a specific task, is hard to defend as "appropriate" under Art 32. The access was not scoped. The risk was not minimized.

A DPIA (Data Protection Impact Assessment) under GDPR Art 35 is required if your processing is likely to result in high risk. Using an AI system to systematically process personal data at scale, in a way that produces outputs affecting those individuals, is the standard trigger. A coding agent that queries a production database with personal data during development sessions is a reasonable candidate for a DPIA, particularly if that access is not scoped or logged.

Your DPO (if you have one) makes the call on DPIA threshold. If you do not have a DPO, the threshold question is whether the processing involves systematic evaluation of individuals, large-scale processing of sensitive data, or automated decisions with significant effects. For most engineering teams using coding agents for code generation tasks, the DPIA threshold is not met unless the agent has persistent access to production data containing personal information.

What the Act mostly ignores

The AI Act does not govern runtime secrets management for development workflows. There is no article that requires you to use a secret broker, rotate credentials on a schedule, or keep API keys out of your agent's context window.

GDPR Art 32 gets you part of the way there, via the security-of-processing obligation. But the Act itself is silent on the mechanics of how you inject credentials into an agent process.

This matters because some compliance frameworks will treat "AI Act compliance" as requiring a large overhaul of your secrets infrastructure. That is not accurate. The Act creates documentation, oversight, and monitoring obligations. It touches secrets indirectly, via GDPR's security requirements when personal data is involved. It does not create a new secrets management standard.

The actual compliance gap for most engineering teams is documentation and scoping, not architecture. You probably already have a secrets manager. The question is whether it is scoped to least privilege, whether agent access is logged, and whether you can demonstrate this to a regulator if asked.

What gets missed in the compliance conversation

Most EU AI Act guides for engineering teams focus on the high-risk system categories in Annex III: biometric identification, critical infrastructure, employment screening. If your coding agent is doing code review and generating pull requests, it is not in any Annex III category. The high-risk obligations (Art 9-25) do not apply.

This is not a loophole. It is the design. The Act intentionally creates a lighter touch for general-purpose AI use in contexts that do not directly affect fundamental rights or safety-critical decisions.

What does apply is the GPAI framework for the model providers you use, and deployer obligations under Art 26 for your use of those models. The practical surface is narrower than most coverage implies.

One thing that does matter, and that most teams skip: Article 26(2) requires you to assign human oversight to a "competent natural person." This is not a formality. A regulator asking for evidence of human oversight over your coding agent's outputs is a reasonable scenario. If your answer is "the agent pushes directly to main," that is a problem independent of secrets management. The audit trail of who reviewed what, and when, is material.

Compliance checklist for engineering teams

## EU AI Act deployer checklist (Art 26 + GDPR Art 32)

- [ ] Inventory of AI tools your team uses (name, version/provider, use case)
- [ ] Confirmation that usage follows provider instructions (link to policy)
- [ ] Named person(s) assigned human oversight responsibility for agent outputs
- [ ] Agent session log retention policy defined (recommend: 90 days minimum)
- [ ] Log retention implemented (CI logs, IDE extension logs, API call logs)
- [ ] DPIA threshold assessed if agents access personal data
- [ ] DPIA completed if threshold is met
- [ ] Access to personal data scoped to minimum necessary for the agent's task
- [ ] Secret access scoped to least privilege per agent profile
- [ ] Secret access logged (who requested, which secret, which process, when)
- [ ] GPAI model providers documented with links to published model cards
- [ ] Review process documented: who approves agent outputs before production
- [ ] Annual review scheduled for this checklist

Run this past your DPO before treating it as complete. Art 26 obligations depend on whether the AI system in your workflow qualifies as high-risk. For most coding agent use cases, it does not, and the checklist above covers the deployer obligations that remain.

What this means for your stack

The compliance surface here is narrower than most legal teams assume, and mostly handled by things you probably already do: access controls, log retention, code review before merge. The gap is documentation and scoping, particularly whether your agents have broader access to secrets and data than the task requires.

If a regulator asks, you want to show documented least-privilege access: the agent got a scoped credential, it expired after the session, the grant is in a log, and a human reviewed the output before it went anywhere. That chain of evidence is the practical requirement under Art 26 and GDPR Art 32.

hasp is one working implementation of this model. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and the agent receives a scoped reference instead of a full credential. The HMAC-chained audit log at ~/.hasp/audit.jsonl gives you the grant record. hasp audit --verify gives you tamper evidence. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

The compliance argument does not depend on any particular tool. It depends on whether you can demonstrate scoped, logged, human-reviewed agent access. The architecture that makes that demonstration easy is the one worth building toward.