AI coding agents such as Cursor, Claude Code, GitHub Copilot and other agentic development tools are changing how developers build and deploy software.

They can read your code, modify files, run terminal commands, execute tests and, depending on how they are configured, interact with your servers and deployment infrastructure.

That power is useful - but it also introduces a security problem:

How do you give an AI coding agent enough access to deploy and troubleshoot your application without giving it the keys to your entire infrastructure?

The answer is not simply "put your password in a .env file."

The better approach is to use least privilege, scoped credentials, SSH keys, CI/CD secrets and separate deployment accounts.

Here is a practical approach.

1. Never Paste Your VPS or cPanel Password Into an AI Chat

This should be your first rule.

Avoid prompts like:

My VPS password is MySuperSecretPassword123.

SSH into the server and deploy my application.

Or:

cPanel username: myuser
cPanel password: MyPassword123

Even if you trust the AI tool, you are unnecessarily exposing a credential through a conversation.

That credential could potentially appear in:

• Chat history
• Terminal output
• Agent logs
• Debug output
• Screenshots
• Project files
• Shell history
• Deployment logs

More importantly, you are giving the AI agent a secret that may provide far more access than the task actually requires.

Instead of asking:

"How do I give Cursor my server password?"

ask:

"How do I let Cursor perform this task with the minimum access required?"

That change in mindset is the foundation of secure AI-assisted development.

2. Use Environment Variables - But Understand Their Limitation

For local development and deployment scripts, environment variables are much better than hardcoding credentials into your application.

For example:

CPANEL_FTP_HOST=ftp.example.com
CPANEL_FTP_USER=my_deployment_user
CPANEL_FTP_PASS=your_password

Your deployment script can then read these values.

For example:

import os

host = os.getenv("CPANEL_FTP_HOST")
username = os.getenv("CPANEL_FTP_USER")
password = os.getenv("CPANEL_FTP_PASS")

And make sure .env is ignored by Git:

.env
.env.*
!.env.example

You can safely commit a template:

CPANEL_FTP_HOST=
CPANEL_FTP_USER=
CPANEL_FTP_PASS=

But here is the important part

.env protects your secrets from being committed to Git. It does not necessarily protect them from an AI coding agent.

If Cursor can read your project directory, it may be able to read .env too.

Therefore, don't think:

"It is in .env, so the AI cannot see it."

Instead think:

"The secret isn't in my source code or Git history, but I still need to control who and what can access the environment."

3. Prefer SSH Keys Over Password Authentication

For VPS access, SSH keys are generally preferable to passwords.

Generate an Ed25519 key:

ssh-keygen -t ed25519

You will typically have:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

The public key goes to the server.

The private key stays on your machine.

Never share the private key:

id_ed25519

The public key:

id_ed25519.pub

is the one intended to be installed on the server.

You can then connect using:

ssh [email protected]

This eliminates the need to paste a server password into an AI conversation.

But there is another important issue

An SSH key is only as safe as the account behind it.

If your key connects as:

root@production

you have potentially given the AI agent full control over the server.

That is not much better than giving it the root password.

4. Create a Dedicated Deployment User

Instead of giving an AI agent root access, create a dedicated user:

deploy

Give that user access only to what it needs.

For example:

/var/www/myapp

rather than the entire server.

Your architecture becomes:

AI Agent
   |
   v
SSH Key
   |
   v
deploy user
   |
   v
/var/www/myapp

Instead of:

AI Agent
   |
   v
root credentials
   |
   v
Entire VPS

This is the principle of least privilege.

If the deployment credential is compromised, the potential damage is limited.

5. For cPanel, Create a Dedicated Deployment Account

The same principle applies to cPanel.

Your main cPanel account may have access to:

• Websites
• Databases
• Email
• DNS
• FTP
• SSL
• Cron jobs
• Backups
• File Manager

There is usually no reason for a deployment script to have access to everything.

Instead, create a dedicated FTP/SFTP account for the application.

For example:

Username:
myapp-deploy

Directory:
/public_html/my-app

Now the deployment credential is associated with the application rather than your entire hosting account.

If the credential is compromised, the attacker does not automatically get your entire cPanel account.

Where supported, prefer secure protocols such as SFTP or SSH over plain FTP.

6. Separate Development, Staging and Production Credentials

Don't use the same credentials everywhere.

Avoid:

Development -> Production credentials
Staging     -> Production credentials
Production  -> Production credentials

Instead:

Development
   |
   +-- Development credentials

Staging
   |
   +-- Staging credentials

Production
   |
   +-- Production credentials

This becomes especially important when working with AI agents.

Give your development environment access to test credentials whenever possible.

For example, if you are integrating a payment API, use sandbox credentials during development instead of your live production secret.

The same principle applies to:

• Databases
• Cloud accounts
• SSH
• Payment APIs
• Email providers
• Third-party APIs

7. Keep Production Secrets Out of the AI Agent Where Possible

For production deployments, a better architecture is to let the AI agent work on the code while your CI/CD system handles the production credentials.

For example:

Cursor
   |
   | git push
   v
GitHub
   |
   v
CI/CD
   |
   | Deployment secrets
   v
Production VPS

Your GitHub repository contains the code and deployment workflow, but not the actual production password.

Secrets can be stored in your CI/CD platform's secret store.

For example:

DEPLOY_HOST
DEPLOY_USER
DEPLOY_SSH_KEY

The workflow uses those values during deployment without putting them directly into the repository.

This creates a useful separation:

AI agent -> code

CI/CD -> production deployment

That is often safer than allowing the AI agent to directly administer production.

8. Give AI Agents the Minimum Access They Need

Before giving an AI agent access to anything, ask:

What does it need to do?

For example:

Deploy my application.

What does it need to access?

/var/www/myapp

What permissions does it need?

Read + write application files

How long does it need access?

Only during deployment

Then create credentials around those requirements.

Don't start with:

"Here is my root password. Figure it out."

Start with:

"This deployment user can only modify this application's directory."

9. Watch Your Terminal Output

Credentials can leak even when you don't explicitly paste them into a chat.

Avoid commands such as:

echo $CPANEL_PASSWORD

or:

env

if your environment contains secrets.

Also be careful with shell debugging such as:

set -x

because commands containing sensitive values may appear in terminal or CI/CD logs.

Your rule should be:

Secrets should not appear in source code, terminal output, application logs or CI/CD logs.

10. What If You Already Shared a Credential?

If you have already pasted a production password, API key or private key into an AI conversation, don't simply delete the message and assume the problem is solved.

Treat the credential as potentially exposed.

Rotate it.

A simple response procedure is:

1. Identify the exposed credential
2. Revoke it
3. Generate a replacement
4. Update the application or deployment system
5. Review authentication and server logs
6. Check for suspicious activity
7. Review how the credential was exposed

For an SSH key, generate a replacement key and remove the old public key from the server.

For an API key, revoke the old key and generate a new one.

For a password, change it.

Credential rotation is more important than simply deleting the leaked secret from the conversation or code.

A Practical Secure Setup

For a small VPS or SaaS project, you don't need a complicated enterprise security architecture.

A practical setup could look like this:

                  +----------------+
                  |  Cursor / AI   |
                  |     Agent      |
                  +-------+--------+
                          |
                          v
                  +----------------+
                  |  Source Code   |
                  +-------+--------+
                          |
                       Git Push
                          |
                          v
                  +----------------+
                  |    GitHub      |
                  +-------+--------+
                          |
                          v
                  +----------------+
                  | CI/CD + Secrets|
                  +-------+--------+
                          |
                     SSH / SFTP
                          |
                          v
                  +----------------+
                  | Deploy User    |
                  +-------+--------+
                          |
                          v
                  +----------------+
                  | Application    |
                  | Directory      |
                  +----------------+

The AI agent can help you write, test and prepare the application.

The deployment system handles the production credentials.

The deployment account has only the permissions required to deploy the application.

Security Checklist

Before giving an AI coding agent access to your infrastructure, check:

• [ ] I am not pasting my master password into an AI chat.
• [ ] Production secrets are not committed to Git.
• [ ] .env is included in .gitignore.
• [ ] I understand that .env can still be read by an agent with filesystem access.
• [ ] I use SSH keys where practical.
• [ ] Production uses a dedicated deployment user.
• [ ] The deployment user does not have unnecessary root access.
• [ ] cPanel credentials are scoped to the application.
• [ ] Development, staging and production credentials are separate.
• [ ] Production secrets are stored in CI/CD or a secret manager where appropriate.
• [ ] Database users have only the permissions they need.
• [ ] Secrets do not appear in terminal or CI/CD logs.
• [ ] I can quickly revoke and rotate credentials.
• [ ] Destructive production operations require appropriate human approval.

Final Thought

AI coding agents are becoming increasingly capable of interacting with real infrastructure.

The goal should not be to prevent them from doing useful work.

The goal is to limit the damage they can cause if something goes wrong.

Don't ask:

"How can I give Cursor my VPS password?"

Ask:

"How can I allow Cursor to perform this task without giving it unnecessary access to my infrastructure?"

Use environment variables to keep secrets out of source code, SSH keys instead of passwords where practical, dedicated deployment users instead of root, scoped cPanel accounts instead of master credentials, and CI/CD or secret managers for production secrets.

The safest credential is not simply the one that is hidden.

It is the one that has the least power necessary to get the job done.