Why AI agent security is different from traditional automation
Traditional automation executes fixed, predictable logic. An AI agent reasons about live inputs and proposes actions that vary run to run. That flexibility is what makes agents useful, and it is also what introduces new risk. The agent can be influenced by data it reads, exceed intended scope if permissions are too broad, and create an audit gap if you have no log of its decisions.
For SMB and mid-market companies, the most common failure mode is not a sophisticated attack. It is an over-permissioned agent running mass writes without approval gates, or credentials left active after a team member leaves.
Top AI agent threat categories
| Threat | What it looks like | Mitigation |
|---|---|---|
| Prompt injection | Malicious input tricks the agent into ignoring its instructions | Sandbox agent context, validate inputs, log all prompts |
| Over-permissioned access | Agent connects with admin credentials it does not need | Least-privilege OAuth scopes, object-level scoping |
| Data exfiltration | Agent reads sensitive records and surfaces them inappropriately | Field-level read restrictions, output filtering |
| Runaway writes | Agent executes mass updates without human review | Approval gates on all writes, spend caps per agent |
| Stale credential exposure | Rotated API keys still active in agent configs | Centralised token store, rotation alerts |
| Audit gap | No record of what agent decided or wrote | Immutable decision log, per-run trace |
Security controls for AI agents
Scoped OAuth permissions
Every agent connects to a stack with the minimum scopes required. No agent uses admin credentials.
Object-level access control
Define which objects the agent can read and write. Sales agents touch leads. Finance agents touch invoices. No crossover.
Approval gates on writes
Every proposed write goes through a human approval step before execution. No silent background writes.
Immutable audit trail
Every decision, every approval, every write is logged with timestamps and actor IDs. Queryable for compliance.
Spend caps per agent
Set maximum run costs per agent per day. Prevents runaway API usage or cost from a misbehaving workflow.
Credential rotation alerts
Get notified when an OAuth token is near expiry or has been revoked. Avoid silent agent failures caused by stale credentials.
Pre-deployment security checklist
Run through this list before any agent touches a production system.
- OAuth scopes reviewed and narrowed to minimum required
- Object-level access defined per agent (leads, tickets, invoices, never all)
- Approval gate configured for all write operations
- Audit logging enabled and queryable
- Spend cap set per agent
- Agent tested in sandbox mode before production authorisation
- Credential rotation schedule set (minimum quarterly)
- Designated owner for each agent with email alerts on failures
- Incident response plan documented (see below)
Incident response for AI agent issues
When an agent behaves unexpectedly, follow these steps in order.
Step 1: Suspend the agent immediately.
Pause the agent before investigating. Do not wait to understand the root cause before stopping execution.
Step 2: Review the audit trail.
Pull the decision log for the affected run. Identify what data the agent read, what actions it proposed, what was approved, and what was written.
Step 3: Revoke credentials if compromised.
If the incident suggests credential exposure or prompt injection, revoke the OAuth token immediately. Re-authorise with narrower scopes after the root cause is resolved.
Step 4: Reverse any incorrect writes.
Use the audit trail to identify which writes need to be reversed. Work through the affected stack (Salesforce, Zendesk, QuickBooks) to undo incorrect data changes.
Step 5: Fix the root cause before reactivating.
Update the agent's instructions, narrow its permissions, or add validation before restoring it to production.
Frequently asked questions
Do AI agents create new security risks compared to traditional automation?
Yes. Traditional automation executes fixed logic. AI agents reason about inputs and propose varied actions each run. That reasoning can be manipulated (prompt injection), and the outputs can be unpredictable if not bounded by scoped permissions and approval gates.
How does Pinksheep handle agent permissions?
Each agent connects to a stack via scoped OAuth. You define which objects it can read and which fields it can write. Every proposed write goes through an approval gate before execution. The platform enforces these boundaries at the API level.
What is prompt injection and how do we defend against it?
Prompt injection is when data the agent reads (a ticket body, a CRM note, an email) contains instructions designed to override the agent's original task. Defend against it by validating and sanitising inputs, sandboxing agent context, and logging every prompt so anomalies are detectable.
Who should own agent security in a small technical team?
The technical enabler who deploys the agents owns permission scopes and access control. Non-technical team leads own the approval gates for their department's workflows. Security policy sits with whoever manages your SaaS security baseline.
How often should we audit agent permissions?
Review active agent permissions quarterly, or immediately after any stack credential rotation, personnel change, or incident. Remove permissions from agents that have not run in 30 days.