Onboard a remote technology engineer

Git identity, repositories and contribution rules

Invite the colleague to the GitHub, GitLab or Bitbucket organisation and relevant teams. Explain Git, branches, pull or merge requests, review rules and code owners. Use SSO and MFA when available. Prefer narrowly scoped, short-lived tokens; protect SSH keys with a passphrase and maintain an inventory.

• Test cloning, private repository access and branch creation.
• Protect main branches and prevent unauthorised approval bypass.
• Never share a Git account or copy a private key between people.

Reproducible development without committed secrets

Provide the README, runtime versions, locked dependencies, installation commands, migrations and tests. Docker, Dev Containers or hosted environments can reduce differences; validate compatibility. Prepare package, image and artifact registry access. Example configuration describes required variables without containing credentials.

• Provide approved synthetic or anonymised development data.
• Test startup, a local database or sandbox, and the first API call.
• Document mock limitations and staging access.

From a ticket to a release

Tickets describe the problem, acceptance criteria, risks, tests and approver. A small first change follows the normal flow: branch, tests, review, staging and authorised release. Grant production access only when the role requires it, with time limits and auditability.

• CI service identities are not personal accounts.
• Keep environments, cloud budgets and permissions separate.
• Prepare a rollback procedure before the first release.

IP allowlists and stable egress

Residential and mobile IPs may change; carrier-grade NAT can share a public IP between subscribers. If a service requires an allowlist, define an approved gateway or business egress with a stable public IP, then verify the address actually seen by each service. A private VPN address, subnet router and public egress IP are different things.

• Ask the service owner about IPv4, IPv6, fallback IPs, ports and protocols.
• A dedicated public IP is not automatically included in a VPN plan.
• Do not allow an entire country or expose a sensitive Internet port to unblock onboarding.

A business VPN needs an operating model

Tailscale, OpenVPN Access Server and WireGuard support different architectures. Tailscale requires an exit node to route Internet traffic through a chosen gateway; that gateway needs a stable public IP when the target service requires one. With OpenVPN or WireGuard, server operations, patching, routes, identities and continuity also need owners. A consumer VPN does not replace these controls.

• Define full or split tunnelling, DNS and access only to required networks.
• Test throughput, latency, reconnects, device sleep and backup connectivity.
• Do not bypass a provider’s geographical or contractual restrictions.

Zero Trust and infrastructure access

Cloudflare Access, Twingate or Teleport can control access by identity, application, device and duration. They are not interchangeable: compare the protocols and resources actually supported. Application access does not guarantee a dedicated egress IP, which may require another service, routing configuration or plan.

• MFA, device posture, least privilege, audit logs and expiring sessions.
• For SSH, databases or Kubernetes, prefer temporary access through a controlled gateway.
• Maintain a documented and tested break-glass process without disabling general security controls.

Minimal, reviewable and revocable permissions

Link accounts to the company directory and use suitable MFA. Provide recovery methods without keeping them alongside the password. Formalise privileged access approval, review and expiry. Document exceptional local administrator use and the reporting process for lost equipment.

• Use a team vault for necessary shared credentials, never plain-text chat.
• Use an application secrets manager with rotation and read auditing.
• If a secret leaks, revoke and replace it; deleting a file does not remove Git history.

Approved working data

Classify code, customer information, logs and models. Grant only necessary access, prefer synthetic datasets and avoid local production copies. For international personal data access, have the appropriate owner review roles, contracts, countries, transfers, subprocessors and retention. Pseudonymisation does not necessarily make data anonymous.

• Include exports, backups, screenshots, notebooks and logs.
• Separate test, validation and production data.
• On departure, revoke accounts, sessions, keys and tokens, recover equipment and transfer resource ownership.

The right account, terms and data

For Claude and Claude Code, ChatGPT and Codex, or GitHub Copilot, clarify the product, interface and licence. A chat subscription is not automatically an API budget. Approve data processing, retention, training policies, regions, subprocessors and terms for the exact product. Personal and business account policies may differ.

• Specify permitted repositories and prohibited data categories.
• Never place secrets or unauthorised customer data in prompts.
• Set budgets, quotas, account ownership and licence removal procedures.

Technical boundaries for agents

Run agents in an isolated environment with minimum permissions and controlled network access. Review commands, dependencies and changes before accepting them. Connectors and MCP servers may extend access to data and systems, so they need approval, boundaries and audit trails. Instructions found in a repository or web page may be malicious.

• No production access or real secrets by default.
• Do not broadly disable approval prompts on sensitive devices.
• Require tests, human review, licence checks and an explanation of delivered code.

A verifiable definition of done

Include business acceptance, relevant tests, human review, dependency checks, secret scanning and documentation. Match controls to risk without treating coverage as a quality guarantee. Validate migrations and API compatibility; passing a mock test does not prove a real integration.

Staging, release and rollback

Define who authorises release, timing and success criteria. Depending on the product, use progressive activation, feature flags or canaries. Document shutdown, rollback and data migrations, which may be harder to reverse than code. Run a practice exercise in a test environment.

Observability and learning

Connect sanitised logs, metrics and traces to understandable dashboards. Alerts need an owner and an action. Define reporting, escalation and blameless learning. Also validate accessibility, performance, restoration and cost according to the risks.

Start with existing tools and constraints

Inventory accounts, contracts, integrations, operating systems, skills and customer requirements. Compare hosting, exportability, auditability, administration, support, variable costs and data locations. A feature may depend on a plan, add-on, region or infrastructure you must operate.

Validate a real scenario before scaling

Test a representative task with one person, approved data and a spending cap. Record results, limitations and costs. Add a tool only to address a demonstrated gap; retire redundant access and assign subscription owners.