Mike Anderson

Posted on May 21

Securing AI Assistants and AI Agents: A Practical Guide for Cybersecurity, DevOps, and Engineering Teams

#ai #security #devops #architecture

Opening

Many teams now use tools like ChatGPT, Claude, and AI coding assistants to write, troubleshoot, summarize, investigate, and automate work.

That creates a practical security question:

Do we need to build a secure harness around every AI tool?

No.

For normal AI assistant use, the priority is governance: policy, workspace settings, data handling rules, connector access, and human review.

For an AI agent that can read internal systems, call tools, open pull requests, query cloud APIs, change tickets, run commands, or trigger workflows, the risk changes. At that point, the model is part of a system that can affect enterprise data and operations. That requires secure architecture around the model.

A simple rule works well:

AI assistant: govern the usage.

AI agent: govern the architecture.

The distinction matters because the controls are different.

1. Daily AI Assistant Use: Govern the People, Data, and Workspace

A daily AI assistant is typically used through a web app, desktop app, mobile app, browser extension, IDE plugin, or approved enterprise workspace.

Examples include:

A security analyst asking AI to summarize an alert.
A DevOps engineer asking AI to explain a Terraform error.
A developer asking AI to review a function.
A manager asking AI to rewrite a technical email.
An engineer asking AI to explain Kubernetes networking.

In these cases, the AI tool is usually not directly controlling production infrastructure. The vendor controls most of the model platform, orchestration, and backend safety layer.

Your organization controls something different: how the tool is used inside the business.

What your organization controls

Area	Practical meaning
User behavior	What employees may paste, upload, or ask
Workspace administration	SSO, MFA, admin roles, apps, connectors, retention, and access controls
Data access	Which files, repositories, drives, or internal systems may be connected
Sensitive data rules	Whether users may submit code, customer data, regulated data, logs, or incident details
Human review	When AI output must be checked before use
Logging and audit	Whether workspace activity and app usage are available for investigation
Approved use cases	Which teams may use AI and for what business purpose

For daily AI assistant use, the first job is not to build a custom agent platform. The first job is to write clear rules that employees can understand and follow.

2. Production AI Agents: Secure the System Around the Model

A production AI agent is different from a normal chat assistant.

A production AI agent may:

Read Jira tickets.
Search GitHub repositories.
Run tests.
Open pull requests.
Query AWS, Azure, or Google Cloud APIs.
Summarize SIEM alerts.
Create Slack updates.
Call internal APIs.
Query a database.
Start a CI/CD workflow.
Recommend or trigger remediation.

At that point, AI is no longer only helping someone write a sentence. It is connected to business systems.

That requires a controlled environment around the model. This environment is often called the agent harness, orchestration layer, or agent runtime.

The name matters less than the purpose.

A secure agent architecture decides:

Who is allowed to use the agent.
What data the agent can access.
What tools the agent can call.
What actions require human approval.
What actions are blocked.
What logs are captured.
What secrets are hidden from the model.
What happens if the agent makes a poor decision.
How output is validated before it is trusted.

A production agent should not have direct, unrestricted access to production systems. It should interact through approved tools, scoped permissions, policy checks, and auditable workflows.

3. The Real Control Trigger

The key question is not only whether something is an “assistant” or an “agent.”

The better security question is:

Can the AI system access internal data or cause a business-impacting action?

If the answer is yes, the control level must increase.

Scenario	Main control focus
Employee uses AI to rewrite an email	Usage policy
Engineer uses AI to explain code	Data handling policy
Team connects AI to Google Drive or SharePoint	Connector access governance
Developer uses an AI coding assistant on a repository	Secure development workflow controls
AI summarizes SIEM alerts	Logging, data access, validation, and analyst review
AI opens pull requests	Repository permissions and code review enforcement
AI can trigger cloud, Kubernetes, IAM, CI/CD, or remediation actions	Secure agent architecture with approval gates

The turning point is simple:

The moment AI can read sensitive systems or take action, the security model must become stronger.

4. Why This Matters

AI risk is not only about the model making a mistake. The larger risk is often about what the model is allowed to access or do.

For cybersecurity teams, the concern is data exposure, unsafe recommendations, missed context, weak logging, and unauthorized access.

For DevOps teams, the concern is production change risk, CI/CD bypass, cloud misconfiguration, secret exposure, and uncontrolled automation.

For engineering teams, the concern is code quality, dependency risk, insecure generated code, repository permissions, and changes that bypass normal review.

The model may produce useful output, but it can also misunderstand context, fabricate details, follow malicious instructions hidden in data, or recommend actions that are technically valid but operationally dangerous.

That is why AI systems need normal engineering discipline:

Identity.
Access control.
Logging.
Testing.
Approval gates.
Rollback.
Incident response.

AI should not be treated as a special exception to existing security and engineering controls.

5. What an AI Usage Policy Should Cover

For daily ChatGPT, Claude, Copilot, Gemini, or other AI assistant use, start with a practical policy.

The policy should be readable. Employees should not need to be lawyers or machine learning engineers to understand it.

Allowed use

Employees may use approved AI tools for:

Drafting and rewriting content.
Summarizing non-sensitive documents.
Explaining code.
Brainstorming solutions.
Troubleshooting support.
Learning technical concepts.
Preparing documentation.
Creating first drafts of runbooks or checklists.

Restricted data

Users must not submit sensitive data unless the AI platform, workspace, and use case have been formally approved for that data class.

Restricted data usually includes:

Passwords.
API keys.
Private keys.
Tokens.
Session cookies.
Customer personally identifiable information.
Payment card data.
Protected health information.
Confidential financial records.
Government-restricted data.
Production secrets.
Sensitive security incident details.
Proprietary source code unless the organization has approved the tool for code use.

Human validation

AI output must be reviewed before it is used for:

Security decisions.
Legal or compliance statements.
Customer-facing communication.
Production code.
IAM changes.
Cloud configuration changes.
Incident response actions.
Vulnerability remediation.
Executive reporting.

This is not because AI is useless. It is because AI output is not evidence by itself. Humans still need to verify accuracy, context, and impact.

6. Connector Access: The Hidden Risk

Many organizations focus on prompts and forget about connectors.

Connectors can allow AI tools to search or interact with company systems such as Google Drive, SharePoint, Slack, GitHub, Confluence, Jira, CRM systems, or internal knowledge bases.

The practical risk is often that the connector exposes too much internal data.

For example, a user should not be able to ask an AI assistant to summarize executive compensation files, legal documents, HR investigation notes, source code, security incident records, or customer data unless that user already has legitimate access and the use case is approved.

Safer connector practices

Before enabling broad connectors:

Start with a small pilot group.
Use least-privilege access.
Separate HR, legal, finance, security, and executive content.
Do not index highly sensitive folders by default.
Test with normal user accounts, not only admin accounts.
Confirm users cannot retrieve documents they should not see.
Monitor connector usage.
Review app and connector settings regularly.
Document the approved business purpose.
Keep logs for audit and investigation where technically supported.

A connector should follow the same principle as every other enterprise integration:

Do not connect everything just because the feature exists.

7. What a Secure AI Agent Architecture Looks Like

When building a custom AI agent, the model should be only one part of the system.

A safer architecture looks like this:

User
  |
  v
Application or Agent Frontend
  |
  v
Policy Gateway
  - authentication
  - role check
  - data classification check
  - request logging
  - prompt and input filtering
  |
  v
Agent Orchestrator / Harness
  - system instructions
  - task state
  - memory boundaries
  - tool routing
  - approval logic
  - retry and stop conditions
  |
  v
Model API
  - approved hosted model
  - approved private model
  - approved local model
  |
  v
Tool Execution Layer
  - Jira
  - GitHub
  - SIEM
  - cloud APIs
  - database
  - sandboxed shell or code runner
  |
  v
Validation Layer
  - output checks
  - policy checks
  - security review
  - human approval when required
  |
  v
Final Action or Response
  |
  v
Logs, Traces, and Audit Evidence

The important point is this:

The model should not directly access production systems. It should go through controlled tools.

This gives security and engineering teams places to enforce policy, inspect activity, approve risky actions, and investigate incidents.

8. Minimum Controls for a Production AI Agent

Before an AI agent touches internal systems, require a baseline set of controls.

Control	What it means in practice
Identity	Every action maps to a real user, service account, or approved workload identity
Least privilege	The agent only gets the permissions required for its approved use case
Tool allowlist	The agent can call only approved tools and APIs
Data classification	The agent knows which data classes it may process
Secrets isolation	Secrets are never exposed directly to model prompts or memory
Human approval	High-impact actions require approval before execution
Change control	Production-impacting actions follow normal SDLC or change processes
Sandboxing	Code, shell, and file operations run in restricted environments
Logging	Prompts, tool calls, decisions, approvals, and outputs are recorded where appropriate
Monitoring	Abnormal tool use, data access, failed actions, and policy denials are detectable
Rollback	Actions can be reversed or remediated if the agent behaves incorrectly
Incident response	The agent has an owner, disable path, and investigation process

These are not theoretical controls. They are the minimum needed to operate an AI agent like any other production system.

9. Example: AI Coding Assistant

An AI coding assistant can be low risk or high risk depending on how it is used.

Risky approach

A developer installs an unapproved extension, gives it access to private repositories, allows it to send source code externally, accepts generated code without review, and merges it into production.

The risk is not only that the code may be wrong. The risk is that normal SDLC controls have been bypassed.

Safer approach

A better model is:

Use an approved coding assistant.
Confirm whether source code is retained, used for training, or shared with third parties.
Restrict repository access by role.
Keep branch protection enabled.
Require pull requests and peer review.
Run SAST, SCA, secret scanning, and tests.
Require security review for authentication, authorization, cryptography, and data handling changes.
Treat AI-generated code like human-generated code: useful, but not automatically trusted.

Policy wording

AI-generated code must follow the same secure development lifecycle requirements as human-written code. AI output does not bypass peer review, automated testing, security scanning, or production change approval.

10. Example: AI Agent for SOC Triage

A SOC triage agent can be useful, but it must be constrained.

Safer workflow

The agent may:

Read alerts.
Summarize relevant evidence.
Enrich indicators.
Correlate identity, endpoint, cloud, and network telemetry.
Suggest severity.
Recommend next steps.
Draft a case note.

The analyst still approves:

Account disablement.
Host isolation.
Firewall blocking.
Token revocation.
User notification.
Incident declaration.
Case closure.

Unsafe workflow

The agent automatically disables users, isolates endpoints, blocks IPs, closes alerts, or declares incidents without confidence scoring, approval gates, rollback, and audit logs.

That creates operational risk. A false positive could disrupt users, break production services, or hide a real incident.

Policy wording

AI may assist SOC triage by summarizing and enriching alerts. Human approval is required before containment, customer impact, incident declaration, or case closure unless a specific automated response playbook has been risk-approved and tested.

11. Example: AI Connected to Company Documents

Document connectors are powerful, but they can create data exposure if deployed carelessly.

Common mistake

An organization enables broad indexing across shared drives and assumes existing permissions are clean.

That is rarely true. Most companies have over-permissioned folders, stale groups, abandoned projects, and sensitive documents stored in places they should not be.

Better approach

Before enabling broad document access:

Clean up high-risk repositories.
Review group permissions.
Remove stale users.
Separate sensitive functions.
Test with realistic user accounts.
Log retrieval activity.
Define approved use cases.
Create an exception path for restricted content.

Security review question

Before approving a connector, ask:

If a normal employee asks the AI assistant the wrong question, could it retrieve data they should not see?

If the answer is yes, fix access control before enabling the connector.

12. Implementation Plan: Three Layers

A practical rollout should use three layers.

Layer 1: AI usage governance

Create a simple AI acceptable use policy.

Define:

Approved tools.
Approved use cases.
Restricted data.
Human review requirements.
Ownership.
Exception process.
Disciplinary or enforcement path for misuse.

Layer 2: Workspace administration

Configure the enterprise AI workspace.

Validate:

SSO and MFA.
Admin roles.
User provisioning and deprovisioning.
Connector approvals.
Retention settings.
Logging and export capability.
Data sharing and training settings.
Third-party app controls.

Layer 3: Secure agent architecture

For agents that use tools or touch systems, require:

Architecture review.
Threat model.
Data flow review.
Tool and permission inventory.
Approval gate design.
Logging design.
Abuse case testing.
Incident response plan.
Production owner.

This keeps normal assistant use lightweight while putting stronger controls around higher-risk AI systems.

13. Practical Checklist

For daily AI assistant use

Is the tool approved?
Is SSO enabled?
Are workspace settings reviewed?
Are users trained on restricted data?
Are connectors disabled or governed?
Are logs available for investigation?
Is there a clear exception process?

For AI coding assistants

Is the tool approved for source code?
Are repositories restricted by role?
Are generated changes reviewed?
Are branch protections enforced?
Are SAST, SCA, secret scanning, and tests required?
Are licensing and dependency risks checked?
Are sensitive repositories excluded where needed?

For production AI agents

Is there a named system owner?
Has the agent been threat modeled?
Are tools allowlisted?
Are permissions least privilege?
Are secrets isolated?
Are high-risk actions approval-gated?
Are prompts, tool calls, approvals, and outputs logged?
Is there a kill switch or disable path?
Can actions be rolled back?
Is incident response defined?

14. Common Mistakes to Avoid

Mistake 1: Treating all AI use the same

Not every AI use case requires the same control level.

Using AI to rewrite a non-sensitive email is not the same as allowing an agent to query production logs, change IAM, or open pull requests.

Match the control level to the risk.

Mistake 2: Giving the model direct access to powerful tools

The model should not directly control production tools without policy enforcement.

Use a tool execution layer that validates requests, checks permissions, logs activity, and requires approval for high-impact actions.

Mistake 3: Forgetting about connectors

Prompt rules are not enough if connectors expose too much data.

Connector governance must include access review, data classification, logging, and testing with normal user accounts.

Mistake 4: Allowing AI to bypass SDLC controls

AI-generated code still needs peer review, testing, scanning, and change approval.

The fact that code came from AI does not reduce the need for engineering discipline.

Mistake 5: Logging only the final answer

For agents, the final answer is not enough.

You need enough evidence to reconstruct:

The user request.
The model response.
Tool calls.
Data accessed.
Approval decisions.
Final action.
Errors and policy denials.

Mistake 6: Trusting AI output without validation

AI output can be useful and wrong at the same time.

Validate recommendations before using them for security decisions, production changes, compliance statements, or executive reporting.

Practical Takeaway

For daily AI assistant use, you need governance:

Which tools are approved.
What users can paste or upload.
Which data is restricted.
Which connectors are allowed.
When humans must review output.
Where activity is logged.
Who owns exceptions.

For production AI agents, you need secure architecture:

Identity.
Least privilege.
Tool allow lists.
Approval gates.
Secrets isolation.
Validation.
Logging.
Incident response.

The simplest rule is:

If AI helps a person think, govern the usage.

If AI can touch systems, govern the architecture.

Final Thought

AI can be useful for cybersecurity, DevOps, and engineering teams, but it should not be treated as magic and it should not be given blind trust.

The safest organizations will not be the ones that block every AI tool or approve every new feature without review. They will be the ones that match the control level to the risk.

Start with policy for everyday use. Add workspace controls for enterprise adoption. Build a secure harness when AI becomes an agent that can access data, call tools, or change systems.

That is how teams get the benefit of AI without turning it into an unmanaged production risk.