Working with a DevOps agency does not automatically require full access to your infrastructure.

At Techpipe, information and access follow the task. We begin with the minimum material needed to understand the problem, design the pilot around the smallest practical disclosure, and introduce infrastructure access only when the agreed result requires it.

The controls on this page form a configurable baseline. The exact combination depends on your architecture, policies, risk model, available tooling, and Techpipe’s assigned responsibilities.

For the complete engagement sequence, see How We Work. For shorter contractual and process answers, see the FAQ.

Access is a consequence of scope

The scope should determine the access—not the other way around.

Before requesting infrastructure access, we first consider whether the work can be completed using:

• architecture diagrams and documentation;
• selected repositories or CI/CD configuration;
• sanitized or synthetic data;
• exported logs, metrics, traces, and incident records;
• screen sharing or a client-operated session;
• an isolated lab, development, or staging environment;
• a limited read-only view;
• a client-executed change prepared and reviewed by Techpipe.

This is particularly useful during the initial assessment and paid pilot, when the objective is to qualify the engineers and working model without creating unnecessary production exposure.

No stage automatically grants unrestricted access. If the task can be completed safely with less, we use less.

Access lifecycle

Access should have a clear purpose, owner, approval, start condition, and end condition.

  flowchart LR
    A["Request<br/>Purpose and scope"]
    B["Approve<br/>Owner and conditions"]
    C["Provision<br/>Named, limited access"]
    D["Use and review<br/>Log, monitor, adjust"]
    E["Revoke<br/>Close and verify"]

    A --> B
    B --> C
    C --> D
    D --> E

Before access is provisioned, we agree on:

• the systems and environments in scope;
• the actions the assigned engineers may perform;
• the required permission level;
• the approved connection path;
• authentication and device requirements;
• whether elevated actions require separate approval;
• logging and evidence requirements;
• expiry, review, and revocation conditions;
• incident and escalation contacts.

Confidentiality and NDA

Techpipe can sign an NDA before sensitive technical or business information is shared.

Confidentiality is also supported operationally. An NDA does not replace access control or justify broad disclosure. We aim to:

• request only information relevant to the agreed work;
• restrict access to the assigned engineers;
• use approved storage and communication channels;
• avoid copying production data unless the task explicitly requires it;
• use sanitized or synthetic data where practical;
• agree on retention and deletion requirements for provided materials;
• avoid placing credentials or secrets in tickets, chat messages, documents, or source code.

Any client-specific regulatory, geographic, contractual, or data-handling requirements should be identified before the relevant material is shared.

Baseline access principles

Our default approach is based on the following principles:

• Minimum necessary access. Permissions are limited to the task and responsibility.
• Named identities. Each assigned engineer uses an attributable individual account where the platform supports it.
• No informal credential sharing. Passwords, private keys, tokens, and recovery codes are not exchanged in ordinary chat or tickets.
• Separation of environments. Development, staging, and production access can be granted independently.
• Separate elevation. Routine access and privileged actions do not need to use the same permission level.
• Time limits where practical. Temporary or just-in-time access is preferred for occasional sensitive work.
• Auditability. Authentication, privileged actions, and changes should be attributable through the controls available in your environment.
• Prompt revocation. Access is removed when the task, responsibility, pilot, or contract ends.

Connection and use rules

The exact rules are agreed with each client. A typical access profile may require:

• connection only through an approved VPN, bastion host, PAM platform, or identity-aware proxy;
• an individual account protected by MFA;
• use of a client-managed account rather than a shared Techpipe identity;
• access only from approved devices or source addresses;
• no local download of production data unless explicitly authorised;
• no unapproved credential export, forwarding, or persistence;
• changes through the agreed issue, review, CI/CD, and change-management process;
• work within agreed maintenance windows or incident procedures;
• session or command logging where supported and appropriate;
• immediate reporting of suspected credential loss, unexpected access, or security events.

These conditions can be stricter for production, regulated data, or privileged roles than for documentation and non-production systems.

Multi-factor authentication (MFA)

MFA should be enabled for infrastructure, cloud, source-control, CI/CD, monitoring, secrets, VPN, and administrative access wherever the platform supports it.

The preferred method follows your policy and platform capabilities. Phishing-resistant methods such as hardware-backed security keys or passkeys can be required for sensitive access. Time-based one-time passwords may be used where stronger methods are unavailable.

Recovery codes and fallback methods should be controlled as credentials. MFA should not be bypassed by sharing an already-authenticated account or session.

Identity and access management (IAM)

IAM maps an engineer’s identity to the work they are authorised to perform.

A practical IAM setup should favour:

• individual identities rather than shared accounts;
• single sign-on or federation where appropriate;
• roles and groups rather than one-off direct grants;
• permissions separated by environment and responsibility;
• default-deny or least-privilege policies;
• explicit ownership and approval for sensitive roles;
• periodic review of active identities and permissions;
• rapid disablement when an engineer leaves the assignment.

Where the client operates central identity management, Techpipe engineers can use client-managed accounts and follow the client’s joiner, mover, and leaver process.

Privileged access

Privileged access includes permissions capable of changing security controls, production infrastructure, identity, networking, data, backups, or other critical systems.

Permanent administrator access is not the default. Depending on the task, privileged work can use:

• a separate administrative role or account;
• approval before elevation;
• access limited to a specific system or environment;
• a defined maintenance or incident window;
• peer review or four-eyes approval;
• client-executed commands or changes;
• session recording and command logging;
• automatic expiry after the work is complete.

Emergency access, if required, should have its own activation, notification, review, and credential-rotation procedure.

Just-in-time access

Just-in-time (JIT) access grants permissions only when they are needed and removes them after a defined period.

JIT is useful for:

• occasional production diagnostics;
• scheduled maintenance;
• migrations and releases;
• incident response;
• temporary access to sensitive logs, data, or administrative functions.

A JIT workflow can include a ticket or request, approval by the client owner, automatic role activation, a short expiry, additional MFA, activity logging, and a post-access review.

Where automated JIT tooling is unavailable, the same principle can be implemented through a documented manual grant-and-revoke procedure.

VPN

A VPN can restrict infrastructure access to an approved network path and known identities or devices.

When VPN access is used, we agree on:

• whether access is user-based, device-based, or both;
• MFA and certificate requirements;
• permitted networks, routes, ports, and environments;
• split-tunnel or full-tunnel expectations;
• source-address and device restrictions;
• logging, expiry, and revocation;
• whether the VPN grants network reachability only or also authorisation to individual services.

VPN connectivity is not a substitute for IAM. Reaching a network should not automatically grant broad permissions inside it.

Bastion hosts

A bastion host provides a controlled entry point for administrative access to otherwise private systems.

A client bastion can enforce:

• named accounts and MFA;
• source restrictions;
• short-lived SSH certificates or keys;
• access to only approved target systems;
• central session and command logging;
• disabled direct access to private hosts;
• separate permissions for staging and production;
• immediate revocation at the entry point.

Credentials used beyond the bastion should remain scoped to their target systems. A bastion should reduce and record the access path, not become a source of shared permanent credentials.

Privileged access management (PAM)

Where a PAM platform is available, Techpipe can use the client’s established workflow for privileged sessions.

PAM may provide:

• approval-based account checkout or session launch;
• automatic credential injection without revealing the secret;
• temporary privileged accounts or roles;
• session recording and command audit;
• credential rotation after use;
• restrictions by user, system, time, and purpose;
• emergency or break-glass workflows.

PAM requirements should be defined before the pilot if the pilot needs privileged access, since provisioning and approvals can affect its schedule.

Secrets management

Credentials and secrets should be stored and delivered through an approved secrets-management mechanism rather than embedded in source code, CI/CD variables copied between projects, documents, or chat messages.

Depending on the environment, this may include:

• a central secrets manager or vault;
• cloud-native secret stores;
• workload identity instead of static credentials;
• short-lived tokens, certificates, or SSH credentials;
• scoped service accounts;
• automatic rotation;
• separate secrets for environments and services;
• audited access to sensitive values.

Techpipe should receive only the secrets required for the assigned task. Whenever possible, systems should inject credentials directly so engineers can use the authorised function without viewing or copying the underlying secret.

Any credential exposed during troubleshooting or included in transferred material should be treated as compromised and rotated.

Changes to production

Access to production and permission to change production are separate decisions.

Before production changes, we agree on the applicable process, which may include:

• an approved issue or change request;
• code and Infrastructure as Code review;
• automated validation and CI/CD deployment;
• a maintenance window;
• backup or restore verification;
• rollback steps and stop conditions;
• monitoring during and after the change;
• client approval for high-impact actions;
• a documented result and any follow-up work.

During an incident, an agreed emergency process may shorten the normal path, but the action, decision, and outcome should still be documented afterward.

Logging, review, and incident reporting

Where your tooling supports it, access and significant actions should be attributable to an individual identity and retained according to your policy.

Relevant evidence may include:

• identity-provider authentication events;
• cloud, Kubernetes, operating-system, database, VPN, bastion, and PAM logs;
• source-control and CI/CD history;
• ticket approvals and change records;
• secrets-manager access events.

If an assigned engineer detects unexpected permissions, suspected credential exposure, unauthorised activity, or another security concern, work affecting the relevant system should pause when safe to do so and the agreed client contact should be notified promptly.

The incident path, response time, evidence preservation, containment authority, and communication responsibilities should be agreed before high-risk or managed-service work begins.

Revocation and offboarding

Access removal is part of the engagement, not an afterthought.

When a pilot ends, an engineer leaves the assignment, responsibilities change, or the contract closes, the offboarding checklist may include:

• disabling client-managed user accounts;
• removing IAM roles and group membership;
• terminating active sessions;
• revoking VPN, bastion, PAM, and JIT permissions;
• revoking tokens, certificates, SSH keys, and API credentials;
• rotating shared or potentially exposed secrets;
• removing access to repositories, CI/CD, monitoring, and documentation;
• confirming handover and handling of retained client materials.

The client remains in control of client-owned systems and can revoke access at any time.

Shared responsibility

Security responsibilities depend on the engagement model and must be explicit.

Before work begins, both sides should understand:

• which systems Techpipe operates, changes, observes, or advises on;
• which decisions require client approval;
• who owns identity provisioning and revocation;
• who manages backups, recovery, patching, certificates, secrets, and monitoring;
• who declares and coordinates an incident;
• what coverage and response targets apply;
• what remains entirely the client’s responsibility.

Techpipe’s access does not transfer ownership of the client’s security programme, compliance obligations, or business decisions unless a specific responsibility is explicitly included in the agreement.

Define the access profile for your pilot

Tell us what problem you want to test, what information you can share, and which access constraints apply. We will identify a pilot scenario that uses the smallest practical disclosure and introduce you to the engineers proposed for the work.

Request an initial assessment