The question is what AI can do in your business
An AI assistant that suggests a reply and an AI agent that changes a customer’s account are different business decisions. The second can create consequences before anyone reads the result. Before connecting an agent to Salesforce, ask three questions: what can it see, what can it change, and who is responsible when it gets something wrong?
For Australian businesses planning AI adoption, that is a more useful starting point than deciding whether AI is universally safe or unsafe. Assess the particular task, information and authority you are handing over.
What the All-In discussion gets us thinking about
In All-In’s “AI Cyber Panic, Ken Griffin’s Bubble Warning, The Fall of France?”, the hosts and guest Nikesh Arora discuss AI-enabled cyber threats, the difficulty of securing complex systems, and responsibility when agents act on someone’s behalf. The sections around 20:47–26:56 are particularly relevant to business owners: credentials, accountability and understanding the systems you already operate.
Our takeaway is practical: define an agent’s authority before giving it access. This article uses the discussion as a starting point, not as independent verification of every incident or prediction mentioned in the episode. The controls below draw on Salesforce, OWASP and Australian cybersecurity guidance, alongside Adaptal’s suggested implementation approach.
Three AI security risks to separate
Data exposure: information reaches an account, person or service that should not receive it. Our earlier guide covers employees pasting customer data into ChatGPT. Agents add another question: what information can they retrieve automatically?
Untrusted instructions: text in an email, document or web page can try to steer an AI away from its intended task. Treat customer-supplied material as information to assess, not authority to change your business rules.
Excessive agency: an agent has more tools, permissions or freedom than its job requires. OWASP’s guidance on excessive agency recommends limiting functionality and permissions, with human approval for consequential actions. A confident answer is not evidence that an action is authorised.
These risks can combine. For example, a malicious instruction in an incoming message becomes more serious when the agent can also export customer records or alter payment details. Reducing its authority limits what a mistake can do.
What this means for Salesforce and Agentforce
Salesforce’s Agentic Enterprise Trust guidance describes a shared responsibility model. Platform safeguards do not replace the customer’s work on agent permissions, configuration and monitoring. The running user can depend on how the agent is invoked, so establish which identity actually executes each action.
Review object, field and record access as well as the actions available to the agent. Use the minimum access required; do not solve a permissions problem by making the agent an administrator. Salesforce also distinguishes configuration audit history from runtime monitoring. Check which logging and monitoring capabilities your edition, licences and configuration provide.
Our suggested Salesforce review starts with a task map. For each proposed outcome, list the records it needs, the fields it reads, the changes it can make, and any external system involved. Then test the actual execution path, including Flow, Apex and integrations. Do not assume that a reassuring prompt changes the permissions of the code underneath it.
For example, “help service staff understand an order” does not inherently require changing prices, deleting contacts or exporting every account. Those should be separate decisions with separate controls.
A service agent example: draft first, act with approval
Imagine a customer emails about a delayed order. This is an illustrative workflow, not a report of a customer incident. An agent could summarise the case, retrieve the relevant order status and draft a reply for a service adviser.
Now imagine the message also requests a refund and a new bank account. Letting the same agent execute that request changes the risk. Our recommended design separates the steps:
- Read only the relevant context. Retrieve the case and permitted order information, not an unrestricted customer export.
- Produce a reviewable proposal. Show the adviser the source records and proposed response.
- Validate consequential changes. Use business rules outside the model to enforce allowed actions, values and records.
- Require an authorised person. Route refunds, bank-detail changes or other sensitive actions through the appropriate approval process.
- Record the outcome. Keep enough evidence to identify the request, action, approver and result, without unnecessarily copying sensitive data into logs.
An approval screen should show what will actually happen. “Approve AI response” is too vague when the underlying action changes a customer record or sends information outside the business.
A practical rollout plan for business leaders
The Australian Cyber Security Centre’s guidance for small businesses recommends assessing AI tools, setting rules for their use, protecting sensitive information, checking outputs and educating staff. Turn those principles into a manageable rollout.
| Stage | Decision to make | Evidence to keep |
|---|---|---|
| Choose a use case | What specific problem will this solve? | A named business owner and a measurable outcome |
| Map access | Which records, tools and systems are necessary? | A reviewed permissions and integration map |
| Test boundaries | What should the agent refuse or escalate? | Results for both normal and deliberately difficult requests |
| Launch narrowly | Who can use it, and which actions need review? | A limited release scope and approval rules |
| Operate and improve | Who watches failures and can stop it? | Monitoring, an escalation route and a tested disable procedure |
This table is Adaptal’s suggested planning framework. Begin with a workflow where errors are visible and reversible. Expand authority only after the team understands the results and failure modes. A successful demonstration is useful; it is not the same as evidence from everyday use.
Test the awkward cases, not just the happy path
Include requests from the wrong customer, incomplete records, conflicting information, repeated requests, and messages asking the agent to ignore its instructions. Check what happens when an integration times out or a person rejects an approval. Use test data and a suitable non-production environment.
Decide in advance what counts as failure: an unauthorised record read, an unsupported claim, a duplicate action, or a change made without approval. Assign someone to review the evidence after each material change to the model, prompt, permissions or connected system.
Also test the stop procedure. The person responsible should know how to disable the agent or its integration access and how to recover from a partial action. Keeping the surrounding systems maintained and their access reviewed remains part of the job.
Build useful AI around clear ownership
AI security is a business operating decision as much as a technical configuration. Someone must own the outcome, someone must own the access, and staff need to know when to intervene. Those responsibilities should be visible before the first customer-facing action.
Adaptal helps businesses plan practical AI and Agentforce workflows, review their Salesforce requirements and connect systems with a defined scope. Our Salesforce integration services can help turn a broad idea into a workflow with clear data boundaries and responsibilities. For the people side, see business and technical skills in the AI era.
Published 29 October 2026. Guidance reflects the sources linked above at the time of writing. Product capabilities and licensing vary; confirm the controls available in your environment. Artwork is an AI-generated conceptual illustration.
Questions business owners ask
Is AI safe to connect to Salesforce?
It depends on the workflow, data and permissions. Start with a narrowly defined task, confirm the execution identity, restrict access, test failure cases and require approval for consequential actions. Connecting a tool is not approval for every possible use.
Does Agentforce remove the need for a security review?
No. Salesforce provides platform safeguards, while the business still needs to review its agent configuration, permissions, integrations and monitoring. Check the capabilities and licences available in your organisation.
What should an AI agent be allowed to change?
Only what its approved task requires. Separate reading and drafting from actions such as refunds, deletions, payment-detail changes or external disclosures. Enforce business rules in the action itself and use appropriate human approval.
What is prompt injection in a business workflow?
It is an attempt to steer an AI using instructions in material it processes, such as an email or document. Treat that material as untrusted input. Limit the agent’s tools and permissions so an instruction cannot simply grant it new authority.
Where should an Australian business begin?
Choose one useful, limited workflow. Name its owner, map the data and access, test with non-production information, and document how to approve, monitor and stop actions. Expand only after reviewing the evidence.
Planning AI inside Salesforce?
Let’s define the workflow, the access it needs and the decisions that should stay with your team.