Secure Internal Tools: Managing Access to Your Custom CLIs

Your team has a powerful, custom-built script. It deploys the latest build, resets a staging database, or pulls a critical report. It's a lifesaver for productivity. But how do you share it? Email it? Drop it in a shared Slack channel? A shared Git repo?

Suddenly, that "lifesaver" script becomes a security liability. Who has the latest version? Who is allowed to run it? And more importantly, are the embedded credentials and API keys secure?

Building powerful internal tools is one thing; managing and securing them is a completely different challenge. This is where traditional methods fall short, and where a new, agentic approach shines. With cli.do, you can transform your business logic into powerful, secure command-line interfaces (CLIs) without the security overhead.

The Hidden Dangers of Traditional Internal Scripts

When you build internal tools using traditional shell scripts or simple Python programs, you often bake in security risks without realizing it.

• Credential Sprawl: Scripts that interact with other services need credentials. Too often, these secrets are hardcoded directly into the script, stored in .env files that get passed around, or set as insecure environment variables on user machines.
• No Granular Access Control: Access is usually all-or-nothing. If a developer has the script, they can run it. There's no easy way to say, "Only senior engineers can run the --production flag" or "Interns can only run this command against the staging environment."
• Zero Audit Trail: Who deployed the broken build at 2 AM? Who reset the customer database? Without a central logging system, answering these questions is nearly impossible. You're left scrolling through Slack messages and terminal histories, hoping for a clue.
• Version and Distribution Chaos: When you fix a bug or update a script, you have to ensure everyone gets the new version and deletes the old one. This manual process is prone to error, leaving outdated and potentially vulnerable tools active in the wild.

These challenges turn what should be a simple utility into a complex management and security problem.

The cli.do Way: Secure by Design

cli.do is a service on the Agentic Workflow Platform that rethinks this entire process. By treating your CLI as an API, it shifts the execution, logic, and security away from the end-user's machine and into a secure, managed cloud environment.

This "Business as Code" approach means you only define the functionality. We handle the rest, including the security.

import { Agent } from '@do-sdk/agent';

// Define your CLI command as an Agent
const cli = new Agent('cli.do');

// Create a 'deploy' command with project and environment arguments
cli.on('deploy', {
  project: { type: 'string', required: true },
  env: { type: 'string', default: 'staging' },
}, async (args) => {
  // Secrets are handled securely on the backend, not the user's machine
  // const API_KEY = process.env.DEPLOYMENT_API_KEY; 

  console.log(`Deploying ${args.project} to ${args.env}...`);
  // Your deployment logic here
  // await triggerDeployment(args.project, args.env, API_KEY);
  return { status: 'success', message: `Deployment of ${args.project} to ${args.env} initiated.` };
});

// Your CLI is now live and callable by authorized users:
// > do cli deploy --project my-app --env production

Here's how this fundamentally solves the security challenges of internal tooling:

Centralized Secret Management

With cli.do, your sensitive credentials, API keys, and tokens live securely on the backend environment where your agentic workflow runs. The CLI tool on your user's machine only sends the command and its arguments (like deploy, --project my-app). The actual logic that uses the secrets is executed in the cloud, never exposing them to the end user.

Role-Based Access Control (RBAC)

Forget all-or-nothing access. cli.do is built on the .do platform's robust authentication and authorization system. This allows you to define exactly who can do what.

• Keep tools private for your personal use.
• Share a command with your immediate team (e.g., the DevOps team).
• Grant specific users or groups access to specific commands (e.g., only Senior Engineers can use the deploy command with --env production).

You have full, granular control to ensure the right people have access to the right tools, and no one else.

Automatic Auditing and Logging

Every time a command is executed through cli.do, the call is logged. You get an immutable audit trail showing:

• Who ran the command.
• What command and arguments were used.
• When it was executed.
• The result of the execution.

This visibility is critical for security, compliance, and debugging. There's no more guessing games; you have a single source of truth for all tool activity.

Instant, Centralized Updates

Found a bug in your deployment script? Just update the code for your agentic workflow. The moment you save it, the CLI is instantly updated for everyone. There's no need to redistribute files or ask team members to git pull. You eliminate the risk of old, vulnerable versions of your tools floating around.

From Risky Script to Secure Internal Tool

Imagine you need a tool to run a database migration.

The old way: A migrate.sh script containing a database connection string. You share it with a new developer, who accidentally runs it against the production database instead of their local one. Disaster ensues.

The cli.do way:

1. You create a db:migrate command using a cli.do agent.
2. The database credentials are stored as secure environment variables in the agent's backend environment. The agent's logic is programmed to never run on the production environment unless a specific, authorized user is making the call.
3. You grant the new developer access to the db:migrate command through the .do platform's access-control panel, but only for the staging and development environments.
4. The developer runs do cli db:migrate --env staging. The command works perfectly.
5. They try do cli db:migrate --env production. The command fails with an "Access Denied" error from the platform. Disaster averted. Every attempt is logged.

Build Powerful Tools, Not Security Problems

Your developers and operators need powerful tools to be effective. But that power shouldn't come at the cost of security and control. By turning your complex processes into managed Command-Line Tools with cli.do, you empower your team while strengthening your security posture.

Ready to stop emailing scripts and start building secure, scalable, and manageable internal CLIs?

Learn more about cli.do and build your first secure command today.