Engineering leads and platform admins make the real decisions about AI engineering workflows. The developers running the tools day to day mostly inherit those decisions rather than making them. An admin who turns on GitHub Copilot's agent mode without configuring its permissions has picked a policy by accident. The pages collected here exist so that choice gets made on purpose instead.
Most of the collection centers on GitHub Copilot administration, because Copilot has more separate configuration surfaces than any other vendor in this space right now. Enablement defaults decide who gets access to an agent before anyone requests it. Agent permissions decide what that agent can touch once it's live: which shell commands run, which files it can edit, which network domains it can reach. Local sandboxing is a separate question from server-side permissions, and admins who assume one covers the other are wrong more often than they'd like. Code review setup decides whether an agent's pull request gets the scrutiny a junior engineer's would, or slides through because a reviewer trusts the label more than the diff. Seat billing decides what a rollout costs once it moves past a pilot and becomes how the team actually works.
GitLab took a different position on agent tool permissions than GitHub did, and reading both is more useful than picking a side early. Outside any single vendor, a CI pipeline that can trigger an agent, paired with an agent that can trigger a pipeline, is a privilege-escalation path that exists whether or not anyone built it on purpose. The UK's National Cyber Security Centre has published its own controls for agentic AI, aimed at exactly this kind of gap. The EU AI Act adds transparency duties on top of that, and they apply regardless of which coding assistant a team standardizes on. Underneath all of it, tool adoption is shifting fast enough that a policy built around one dominant assistant can be out of date before the next procurement cycle.
The stance behind every page here is the same. Treat an agent like a new engineer who showed up already holding credentials: decide what it can see, what it can change without asking, and what needs a second person to sign off, before it starts work rather than after an incident forces the question. Read the vendor's own policy pages instead of a summary of them. The distance between what a tool can technically do and what its default configuration actually permits is where most of these decisions go wrong.
Every guide on AI in the workflow
- GitHub Copilot default enablement policy: what to decide: GitHub Copilot default enablement policy: unconfigured Features, Code Review and MCP servers settings go live Oct 22, 2026. What to decide first.
- GitHub Copilot local sandboxing: what it locks down: GitHub Copilot's local sandboxing (preview, Sept 23) restricts files, network and credentials. What admins control, and what OTel export adds.
- How to set up GitHub Copilot code review in 2026: GitHub Copilot code review now auto-resolves comments and writes commit messages. How to configure it org-wide, and what it still cannot replace.
- How to set GitHub Copilot agent permissions (deny, ask, allow): Copilot enterprise permissions gate shell commands, file edits and network domains with deny, ask or allow. Local settings can't weaken them. GA Sept 9, 2026.
- NCSC agentic AI guidance: the controls to actually configure: The UK's NCSC published controls for running AI agents safely: network isolation tiers, credential scoping, a kill switch. What to actually configure.
- AI Act Article 50 transparency: what engineering teams must build: Article 50 of the EU AI Act took effect 2 August 2026. Here's what providers and deployers must disclose, mark, and ship before the grace period ends.
- GitHub Copilot's new billing rules: what changes 1 October 2026 and what to do now: From 1 October, GitHub charges upfront for every assigned Copilot Business and Enterprise seat paid by card or PayPal. Here's what to audit first.
- GitLab just set a default for AI agent permissions. Here's the policy behind it: GitLab 19.4 gates AI agent tool access: read-only runs free, write and delete need approval. The permissions policy to copy, whatever agent you run.
- AI coding tool adoption in 2026: what JetBrains' survey means for renewals: JetBrains surveyed 15,000+ developers from May to July 2026: Claude Code adoption doubled while Copilot and Cursor fell. What it means for your renewal.
- When your CI agent becomes a privilege escalation path: an audit checklist: Pillar Security found two privilege escalation paths in Google's adk-python CI agents, reachable from public issues. Both are fixed. Here's what to audit.
FAQ
Who should own AI agent permissions, platform engineering or the team using the tool?
Platform engineering should own the default policy, with individual teams given a narrow path to request exceptions and a reason attached to each one. A team that sets its own permissions tends to loosen them under deadline pressure, which is exactly the failure mode a shared policy exists to prevent. Centralizing the decision doesn't mean centralizing every judgment call, since a platform team still needs input from the engineers closest to what an agent actually touches day to day.
Does one AI agent permissions policy work across every tool a team runs?
No, and treating it that way is a common mistake. GitHub Copilot, GitLab Duo, Cursor and Claude Code each expose different controls, different defaults and different override behavior, so a policy written for one tool rarely maps cleanly onto another. The right approach is a shared set of principles, what gets denied, what gets asked, what gets logged, applied separately to each tool's own settings.
What's the most common mistake engineering teams make when rolling out AI coding tools?
Treating the rollout as a tooling decision instead of an access decision. Teams pick an assistant, turn on its agent features, and only look at permissions after something unexpected happens, a merged pull request nobody reviewed, an API call to a domain nobody approved. The fix is ordering the work correctly: decide what an agent can touch before turning it on.