Guardrails, in short

Engineers do work that serves your business; personal or unrelated requests are politely declined. Clearly abusive requests are blocked before any cost and emailed to the alert address; three clear-abuse refusals in 24 hours pause a member until the owner restores them on Members (owners and admins are never paused). Asking about your own files and documents, including keys or code words written in them, is normal work. Content from repos, tickets, web pages, files and tools is treated as information, never instructions. Engineers never print secrets, environment variables or credential files.

Who can instruct your engineers. Only your team: members of the workspace and, on pull requests, people whose GitHub, GitLab or Bitbucket username is on the Team page (Add code usernames on their row; a member can add their own), or on GitHub a collaborator on the repo. A comment on an engineer's PR from anyone else is held: a card in the delivery's Slack thread (or the needs-help channel) asks a team member to Pass it on (the engineer acts on it, marked as passed on by them) or Ignore it; undecided, it lapses after 48 hours. A PR approval moves a human review step only when it's from that step's owner, backup or an admin (with their username on the Team page). Some actions need a person's approval (changing a Jira ticket, a Confluence page). In Slack an admin approves them; in the portal and on pull requests nobody can click approve, so Settings → Who can instruct your engineers chooses: Let them run (a team member's request goes ahead) or Always ask in Slack (the engineer stops and says it needs approval). Interviews and code reviews never run such actions, and nor do meetings: an engineer in a call notes it as a follow-up to ask for in Slack. What's said to an engineer in a meeting is screened like any other message. A single message can be up to 32,000 characters; share longer logs or documents as a file or a link.