AI agents at work: Who can act, and who stays accountable?

Your team wants an AI agent to read supplier documents and prepare follow-up questions. That could save useful preparation time. Once it starts sending emails, changing records or closing tasks, another question arises: Who defines the permitted actions, and who checks the outcome?

TL;DR: Can we use AI agents securely?

• Review the actual workflow: Which data does the agent read, which tools does it use and what can it change?
• Limit permissions: Grant the access needed for its task. A prompt instruction does not replace technical access controls.
• Approve consequential actions: Define when a person must review an action and what they need to see.
• Assign ownership: Business teams, IT and information security need clear responsibilities for introduction and operation.
• Reassess changes: New data sources or write permissions change the deployment you originally reviewed.

As of 13 October 2026. The current event provides the context; the checklist and business example are our editorial recommendations. The cover is an AI-generated illustration.

Why this is timely

The Singapore International Cyber Week programme for 13 October includes a session on agentic AI in cyber operations. This confirms a scheduled topic, not the session's outcomes or decisions.

In her 12 October address, Minister Josephine Teo emphasises human oversight and continuing monitoring of autonomous AI. Our interpretation for businesses: A one-time approval is insufficient if capabilities and integrations subsequently change.

What distinguishes an agent from a text assistant?

An AI agent can translate a goal into multiple steps and use connected tools. Its actual ability to act matters more to your risk assessment than its product name.

An assistant that drafts a reply has different consequences from an integration that sends it directly to customers. Read-only access can also be sensitive: Which documents may the system access, and where can its outputs go?

CSA publishes an addendum to its AI security guidance. The linked PDF identifies version 1.0 dated 17 June 2026 and describes itself as non-mandatory guidance. It is neither a rule introduced today nor a German statutory obligation.

A fictional case: Reviewing supplier documents faster

A procurement team wants an agent to summarise a provider's security documents, identify missing information and draft questions. The intended value is straightforward: less searching and faster preparation of an assessment.

An initially limited deployment could allow the agent to read only approved documents for a particular supplier and create a draft with source references. A responsible person checks the claims and decides on questions and ratings. Write access to supplier ratings and automatic sending remain disabled for this workflow.

A specific risk scenario is: A manipulated document causes the agent to include confidential information from another data source in an external question. Assessment depends on the actual access, data and safeguards. “AI might make mistakes” is too vague to guide action.

Six decisions before production use

Our worksheet brings the relevant teams together. It is not a certification scheme or a verbatim official checklist.

Decision	Question for your team	Verifiable result
Purpose	Which problem should the agent solve?	Defined process and permitted actions
Data	What can it read and disclose?	Approved sources, recipients and boundaries
Access	Which accounts, tools and rights does it need?	Documented, technically constrained access
Approval	Which actions require review before execution?	Defined review steps and owners
Operation	Who detects errors and can stop the workflow?	Contacts, logging and a stop procedure
Changes	When do we review the deployment again?	Review date and triggers such as new write permissions

Approval must support a real decision

A “Confirm” button is insufficient if the reviewer cannot understand the consequences. In our example, they should see the recipient, proposed content and sources. Other applications may require details of record changes or a comparison with the previous state.

Our recommendation: Test rejection and cancellation too. Is the action blocked when approval is absent? Could the agent produce the same result through another tool? Who can revoke access? These questions concern technical implementation in the agent system.

Bring the risks into your existing work

You do not need an isolated spreadsheet for every new agent. Connect the deployment to its business process, affected data and providers. Record the risk scenario and agree actions with an owner, deadline and expected evidence.

A fictional action could be: “Technically prevent external sending without reviewed approval.” Evidence consists of documented configuration and tests of permitted and blocked actions. A responsible person reviews the result; new tools or permissions trigger reassessment.

Kopexa helps coordinate this GRC work through risk management, work items and vendor assessments. Processes provide the business context. Technical enforcement of agent permissions takes place in the connected systems; Kopexa helps you manage ownership, implementation and evidence.

How does this relate to ISO/IEC 27090?

Our ISO/IEC 27090 article on AI security in the ISMS discusses the classification of AI security risks and the standard's status checked there. This article adds the operational question: How does an identified risk become a bounded, verifiable agent deployment?

Start with one use case. Work through the six decisions together, resolve outstanding issues and test the workflow before introduction. If the work currently lives in separate spreadsheets, Kopexa ISMS software shows how to connect risks, responsibilities and evidence. Use your planned workflow as the starting point for a demo.