Four security levels for agentic Power Platform development
Diesen Beitrag auf Deutsch lesen
A practical model for controlling what Claude Code can reach across Power Platform environments, pipelines, local files and separate tenants.
TL;DR
Claude Code can work through four access levels for Power Platform development: a service principal, a developer account limited to dev, local Copilot Studio YAML files, or a separate tenant. Levels 3 and 4 keep customer connections with a human, while customer logins expire after 30 minutes of inactivity and at 17:00.
Original by Karl-Johan Spiik, on Karlex. Read the original
This is our own summary, not a republication or full translation.
Governance takeaway
- Security/Compliance: choose the access level per customer and keep the blast radius explicit, because service principals and developer accounts can reach the customer tenant.
- Admins/CoE: use delegated Power Platform pipelines with approval for dev to test to production, because the pipeline identity deploys the same managed artifact.
- Makers: review cloned YAML files before pushing and test changes yourself, because a pull can report success after a conflict and the agent does not replace human responsibility.
Frequently asked questions
How does delegated deployment change Power Platform pipeline security for an agent?
Delegated deployment uses the pipeline identity instead of the developer account, and each deployment waits for approval before moving forward.
What happens when a Copilot Studio agent is cloned to local YAML files?
The agent edits local YAML without holding an environment token. A human pulls and pushes the changes, after checking for conflicts.
When do customer logins expire on the agent server?
Customer logins are signed out after 30 minutes without activity and at 17:00, with a separate sweep for stuck sessions.