[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-faqs-ai-agent-readiness-before-system-access-en":3,"blog-post-ai-agent-readiness-before-system-access-en":28},[4,8,12,16,20,24],{"answer":5,"id":6,"question":7},"\"AI agent\" usually refers to a single system that takes a goal and calls tools to complete it. \"Agentic AI\" usually describes the broader quality of AI that decides and acts on its own, which may involve several agents working together. In practice the two terms are often used interchangeably. For a readiness assessment, the label matters less than whether the system can call APIs or change data in real systems.","s0gtxjujshe8xd5","What is the difference between an AI agent and agentic AI?",{"answer":9,"id":10,"question":11},"RPA and workflow automation follow steps that a person wrote in advance. An AI agent decides for itself which tool to call and what to do next based on the text it receives. That flexibility lets an agent take on work that is not fixed, but it also makes its behavior harder to predict, so it needs more control gates than traditional automation.","6ffdrhb2cxysrz5","How is an AI agent different from RPA or workflow automation?",{"answer":13,"id":14,"question":15},"Yes. Thailand's National Cyber Security Agency (NCSA) published its AI Security Guidelines on 30 September 2025, including checklist items written specifically for agentic AI. The Ministry of Digital Economy and Society and ETDA announced a Generative AI Governance Guideline for Organizations on 30 October 2024. Whether your organization has legal obligations on this topic is a question for your industry regulator.","2f5ud7bc1mrbjo5","Is there official Thai guidance on AI security or AI governance to reference?",{"answer":17,"id":18,"question":19},"The owner of the business process the agent works in, together with the IT team that runs the systems. The process owner is best placed to judge which tasks cannot be reversed and how much damage a mistake would cause. The security team should also take part in reviewing permissions and logs on a regular basis.","7l728t5vqv6sc49","Who in the organization should own the risk of an AI agent?",{"answer":21,"id":22,"question":23},"At least every time the agent takes on a new task, gets a new tool, or has its model changed, plus a scheduled review cycle like any other service account. The right frequency depends on the risk of the work: an agent with write access to financial systems should be reviewed more often than one that only reads internal documents.","heyr2c2o1q0wvwq","How often should an AI agent's permissions be reviewed?",{"answer":25,"id":26,"question":27},"Work where the agent only reads data, uses non-confidential information, and has its output checked by a person before it is used, such as summarizing internal reports or drafting replies for staff to review before sending. Work like this produces real evidence of how the agent behaves while keeping the damage from any mistake limited.","9la8x5ujzyfjjl4","What kind of use case suits an organization's first AI agent?",{"id":29,"parentId":30,"title":31,"excerpt":32,"content":33,"image":34,"date":35,"isoDate":36,"views":37,"tag":38,"categorySlug":39,"slug":40,"to":41,"readTime":42,"isHighlight":43,"sortOrder":44,"video":45,"video_id":45,"keywords":46},"2xc6hndcwhsz8qw","vj19otactrm4ma0","Before AI Agents Touch Production Systems: 7 Gates Your Organization Must Pass","Pass\u002Ffail criteria for CTOs, CIOs and IT leads before an AI agent is allowed to call APIs, change data or trigger actions in real enterprise systems, from agent identity and least privilege to audit logs and human approval, with references to Thailand's NCSA guidelines and OWASP.","\u003Cp>When a team proposes connecting an AI agent to the organization's real systems, the question that matters most in the meeting room is rarely whether the model is smart enough. The question worth asking is this: if the agent edits a hundred records incorrectly at 2 a.m., who finds out first, and how far back can you roll it? No accuracy benchmark answers that. It is answered by how ready the systems around the agent are before it gets any permissions. This article sets out seven core gates to use as pass\u002Ffail criteria before an agent is allowed to do anything more than read data.\u003C\u002Fp>\n\n\u003Cp>Any gate not yet passed means the agent stays read-only.\u003C\u002Fp>\n\n\u003Ch2>A chatbot answers questions; an agent acts inside your systems\u003C\u002Fh2>\n\u003Cp>The chatbots and copilots many organizations already use work within a narrow loop. They take a question and return text. The person reading the answer still makes the next decision, so if the answer is wrong, the damage stops with whoever read it and believed it.\u003C\u002Fp>\n\u003Cp>An AI agent is different because it acts on its own. Thailand's National Cyber Security Agency (NCSA) defines agentic AI in its \u003Ca href=\"https:\u002F\u002Fwww.ncsa.or.th\u002Fstandards\" target=\"_blank\" rel=\"noopener noreferrer\">AI Security Guidelines\u003C\u002Fa>, published on 30 September 2025, as an \"actor\" that can connect to and command other systems to complete a task automatically. Once an agent can call APIs, read databases and trigger other systems, a wrong answer no longer stays on the screen. It becomes a record that was changed, an email that was sent, or a request that was already approved.\u003C\u002Fp>\n\u003Cp>OWASP calls this risk Excessive Agency and lists it as LLM03 in the \u003Ca href=\"https:\u002F\u002Fgenai.owasp.org\u002Fresource\u002Fowasp-genai-llm-top-10-2026\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">OWASP Top 10 for LLM Applications 2026\u003C\u002Fa>, with three root causes. The agent can reach more tools than its task needs. It holds more permissions on downstream systems than it should. And it can carry out high-impact actions with no one approving them. The seven gates below close those three gaps one layer at a time, and limit the damage when something still gets through.\u003C\u002Fp>\n\n\u003Ch2>Gate one: the agent has its own identity, not a borrowed human account\u003C\u002Fh2>\n\u003Cp>The fastest way to trial an agent is to let it run under the account of whoever set it up, or under a service account that several systems already share. It works immediately. It also makes a basic question impossible to answer: was last night's change made by a person or by the agent?\u003C\u002Fp>\n\u003Cp>The \u003Ca href=\"https:\u002F\u002Fgenai.owasp.org\u002Fresource\u002Fowasp-top-10-for-agentic-applications-for-2026\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">OWASP Top 10 for Agentic Applications 2026\u003C\u002Fa>, under ASI03 (Identity and Privilege Abuse), makes the point directly: an agent without its own governed identity leaves a gap in attributing who did what, and least privilege cannot really be enforced.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Test question:\u003C\u002Fstrong> if you had to shut down one agent right now, could you do it without affecting any person's account or any other system?\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Minimum to pass:\u003C\u002Fstrong> each agent has its own account or workload identity, a named owner by role, and credentials that live in the organization's own cloud account. Why cloud accounts must stay in the organization's hands is something we covered in \u003Ca href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Ftor-conditions-for-a-maintainable-system\" target=\"_blank\" rel=\"noopener noreferrer\">TOR conditions for a maintainable system\u003C\u002Fa> (Thai). The same principle applies to agent identities.\u003C\u002Fp>\n\n\u003Ch2>Gate two: grant only what the task needs, with an expiry date\u003C\u002Fh2>\n\u003Cp>An agent that drafts a monthly report from ERP data needs read access to the relevant tables. It does not need to edit or delete anything. The tools plugged into it, however, often come with far more capability than that. OWASP's LLM03 entry gives the example of a tool meant only to read data that connects to the database with an identity holding UPDATE, INSERT and DELETE rights as well.\u003C\u002Fp>\n\u003Cp>This gate is checked with three questions. Can the agent call only the tools its task requires? Does each tool expose only the functions it needs? Are read and write permissions on downstream systems separated? In the NCSA checklist, item DSG-07 calls for limiting an agentic AI's action space under the principle of least privilege, and DEP-03 applies the same principle to IAM roles in production.\u003C\u002Fp>\n\u003Cp>What usually gets forgotten is the expiry date. Permissions opened during a trial and never closed stay open until the day someone uses them in a way nobody intended. If your organization has no review cycle for service account permissions yet, treat this gate as not passed.\u003C\u002Fp>\n\n\u003Ch2>Gate three: decide which data classes the agent can see\u003C\u002Fh2>\n\u003Cp>Gate two covers what the agent can do. This gate covers what it can see, and the two are separate. An agent with read-only access can still leak data if it pulls confidential records into an answer, or passes them to an external service for processing.\u003C\u002Fp>\n\u003Cp>The test here is whether the organization has a working data classification scheme. Without one, you cannot say which tables the agent should see, or what data it sends outside the organization. In practice, we recommend starting from an allowlist of the tables or folders the agent may access, rather than trying to close off gaps one by one.\u003C\u002Fp>\n\u003Cp>If the data the agent touches includes personal data, what Thailand's PDPA requires should be answered by your legal team or Data Protection Officer (DPO), with reference to guidance from the Personal Data Protection Committee (PDPC). This article is not legal advice.\u003C\u002Fp>\n\n\u003Ch2>Gate four: every API the agent calls needs its own gatekeeper\u003C\u002Fh2>\n\u003Cp>Many internal APIs were designed on the assumption that the caller is a system the team wrote itself, so they have no rate limits and only loose input validation. Agents break that assumption. The values an agent sends come from interpreting text, and that text may come from an email or an outside document carrying hidden instructions (prompt injection).\u003C\u002Fp>\n\u003Cp>NCSA checklist item DSG-06 requires secure defaults for every API, such as enforced authentication and rate limiting. OWASP recommends complete mediation: keep authorization in the system's own logic, and never let the LLM decide whether an action is allowed.\u003C\u002Fp>\n\u003Cp>Legacy systems with no API layer at all are the hardest case. Giving an agent direct access to a legacy database skips this gate entirely. If you are weighing how to modernize an older system, factor this into the \u003Ca href=\"https:\u002F\u002Fwww.superdev.tech\u002Fen\u002Fblogs\u002Flegacy-rewrite-vs-refactor-decision\" target=\"_blank\" rel=\"noopener noreferrer\">rewrite versus refactor decision\u003C\u002Fa> as well.\u003C\u002Fp>\n\n\u003Ch2>Gate five: you can trace what the agent did, and on whose behalf\u003C\u002Fh2>\n\u003Cp>Most system logs show which account changed what, but not why. For an agent, the questions you need to answer after an incident go further: who asked for this task, what input the agent received, which tool it chose to call, and what the downstream system returned.\u003C\u002Fp>\n\u003Cp>NCSA item OPS-06 requires monitoring and logging of every action an agentic AI takes automatically, for later review, and OPS-02 requires logs to be kept in a secure, auditable system.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Test question:\u003C\u002Fstrong> if internal audit asked which items the agent approved last month, and whose request each one started from, could your team answer within a day? If it means piecing things together from several systems, this gate has not been passed.\u003C\u002Fp>\n\u003Cp>One more point: agent logs tend to carry sensitive data, because they record prompts and whatever the agent read. Access to those logs needs to be restricted as tightly as the data itself.\u003C\u002Fp>\n\n\u003Ch2>Gate six: spot anomalies as they happen, and know who can stop the agent\u003C\u002Fh2>\n\u003Cp>An audit log helps after the fact. This gate is about knowing while it is still happening. An agent stuck in a loop calling the same API, or suddenly reaching into data it has never touched, should be caught at that moment. Finding out from the cloud bill at the end of the month is too late.\u003C\u002Fp>\n\u003Cp>OWASP recommends thresholds on tool invocations, with circuit breakers that halt, throttle or escalate to human review when they are exceeded. The NCSA guidelines give a containment example for agentic AI incidents: revoke the API keys and suspend the agent's access to other systems immediately.\u003C\u002Fp>\n\u003Cp>A stop button is only useful if everyone knows who is allowed to press it. If the decision waits for a meeting, the agent keeps working in the meantime. It is the same principle we described in \u003Ca href=\"https:\u002F\u002Fwww.superdev.tech\u002Fen\u002Fblogs\u002Fdr-plan-roles-and-decisions-during-an-outage\" target=\"_blank\" rel=\"noopener noreferrer\">who decides when systems fail\u003C\u002Fa>: criteria and decision-makers are set before the incident.\u003C\u002Fp>\n\n\u003Ch2>Gate seven: separate what the agent may do alone from what needs human approval\u003C\u002Fh2>\n\u003Cp>Human-in-the-loop that works in practice does not mean a person approves every step. If everything waits for a person, the agent is just a slower form, and when every item needs approval, approving gradually turns into clicking through out of habit.\u003C\u002Fp>\n\u003Cp>The approach OWASP sets out in LLM03 is to tier actions by impact and reversibility. Actions with low impact, or that are easy to undo, can run automatically; high-impact or irreversible ones wait for a person. Its example is a refund issued as store credit, which is recoverable and can be automated, versus an external payout, which cannot be undone and needs human approval. Thailand's Electronic Transactions Development Agency (ETDA) takes a compatible line in its Generative AI Governance Guideline for Organizations, which calls for setting the level of human involvement according to the level of risk and potential harm.\u003C\u002Fp>\n\u003Cp>In practice, have the team list every task the agent will perform and answer two questions for each: how bad is it if this goes wrong, and can it be reversed? Irreversible tasks, such as payments, deleting data or sending messages outside the organization, should always require human approval in the early stages. That list also needs an owner who reviews it whenever the agent takes on a new task.\u003C\u002Fp>\n\n\u003Ch2>Where the seven gates sit in your architecture\u003C\u002Fh2>\n\u003Cp>None of these gates belongs in the agent's prompt. Writing \"never delete data\" in a prompt is only a request, and prompt injection can overwrite it. Real control has to live somewhere the agent cannot change.\u003C\u002Fp>\n\u003Cp>The pattern we recommend is a control layer between the agent and your real systems. It can be an API gateway you already run, or a service built for the purpose. Every agent command passes through it. The layer verifies the agent's identity for gate one, checks permissions and data scope for gates two and three, enforces rate limits and input validation for gate four, writes the audit log for gate five, feeds monitoring and accepts stop commands for gate six, and holds actions that await human approval for gate seven. OWASP describes the authorization part of this layer as an independent pre-execution policy decision point.\u003C\u002Fp>\n\u003Cp>The benefit of keeping all of it in one layer is that when the organization changes models, switches agent vendors or adds a new agent, the seven gates stay where they are. The team does not rebuild them each time.\u003C\u002Fp>\n\u003Cp>To be fair, this layer is one more system someone has to run, and it slows down early agent trials. If your agent is still read-only, works with non-confidential data and serves a small team, building the full layer may not be worth it yet. Our advice in that case is to start with gates one, two and five, and add the control layer once the agent starts getting write access.\u003C\u002Fp>\n\n\u003Ch2>A common objection: our AI platform already has guardrails\u003C\u002Fh2>\n\u003Cp>There is truth in this. Enterprise AI platforms usually ship with content filters, tool restrictions and approval screens, and you should turn all of them on. The limitation is that a platform's guardrails only see the agent's side. They do not know which of your tables are confidential, which accounts can approve transactions above a limit, or who has the authority to stop a system.\u003C\u002Fp>\n\u003Cp>And if the organization switches platforms one day, those guardrails disappear with it. The gates that sit on the organization's own side are the ones it genuinely controls.\u003C\u002Fp>\n\n\u003Ch2>Writing the seven gates into your TOR and vendor terms\u003C\u002Fh2>\n\u003Cp>If the agent comes from a vendor or is built by an outside developer, the seven gates only take effect once they are in a document that binds the supplier. Adding them at acceptance testing is usually too late, because the architecture is already set.\u003C\u002Fp>\n\u003Cp>At minimum, the TOR should cover five things. Each agent must have its own identity, held in the organization's cloud account. The supplier must deliver a list of the tools and permissions the agent uses, with a reason for each. There must be an audit log showing what the agent did and on whose behalf, which the organization can access directly. The internal team must be able to stop the agent without waiting for the developer. And the list separating auto-approved actions from those needing human approval must be part of the deliverables. For cloud accounts, the same principle applies as the TOR conditions referenced under gate one.\u003C\u002Fp>\n\u003Cp>If you use an off-the-shelf agent platform, ask the vendor for evidence of how platform-side logs are kept, for how long, and how quickly they must notify you of an incident. Then write those terms into the contract, along the lines we described in \u003Ca href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Fma-sla-contract-checklist-before-signing\" target=\"_blank\" rel=\"noopener noreferrer\">reviewing an annual maintenance contract\u003C\u002Fa> (Thai).\u003C\u002Fp>\n\n\u003Ch2>If you have not passed them all, where to start\u003C\u002Fh2>\n\u003Cp>Not passing all seven gates does not mean stopping the project. The order we recommend is to start with a read-only agent in a single workflow, with its own account and logging from day one. During that period the team learns which tools the agent calls most, what data it runs into, and where it makes mistakes. That evidence designs the remaining gates better than guessing up front.\u003C\u002Fp>\n\u003Cp>When you open write access for the first time, open it only for reversible actions, and route every item through human approval first. Then move low-impact actions to auto-approval once the logs show the agent handles them as expected. This order lets your internal team decide based on evidence from its own systems, instead of relying on a vendor's assurances.\u003C\u002Fp>\n\n\u003Chr>\n\u003Ch2>Summary\u003C\u002Fh2>\n\u003Cp>Readiness for AI agents is measured by the systems around the agent more than by how smart the model is. If you take one thing from this article, ask your team whether the first agent headed for production has its own account yet, and whether there is a log that shows what it did and on whose behalf. Those two are the foundation for every other gate.\u003C\u002Fp>\n\u003Cp>When you take this to a committee for approval, the evidence that helps them decide is a short table showing whether each gate has been passed, the role that owns each gate, and the list of tasks the agent may do on its own. Referencing NCSA checklist item codes such as DSG-07 or OPS-06 shows the committee that the criteria come from more than the team's own opinion.\u003C\u002Fp>\n\u003Cp>If your organization is planning to bring AI agents into its systems and would like someone to walk through these gates against your actual architecture before any permissions are opened, you can see how we work with enterprises on our \u003Ca href=\"https:\u002F\u002Fwww.superdev.tech\u002Fen\u002F#enterprise\" target=\"_blank\" rel=\"noopener noreferrer\">enterprise services page\u003C\u002Fa>. We are happy to talk. No fixed deadline, and no rush to decide.\u003C\u002Fp>\n\n\u003Cp>To discuss a project in detail, reach us at 088-983-9386 or email contact@superdev.tech. Our office is in Bang Kapi, Bangkok. For organizations still drafting their scope of work, we are glad to set up a call to understand the problem first, even before the documents are complete, and if it turns out the problem does not yet call for a new system, we will say so plainly, because starting a project at the wrong time costs more than waiting another quarter.\u003C\u002Fp>\n","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fpbc_2128795511\u002F2xc6hndcwhsz8qw\u002Fcover_cover_k3zun6gh2q.webp","September 25, 2026","2026-09-25 05:57:30.233Z",112,"Enterprise","enterprise","ai-agent-readiness-before-system-access","\u002Fblogs\u002Fai-agent-readiness-before-system-access",13,false,0,"",[47,48,49,50],"AI Agent","Agentic AI","AI Security","AI Governance"]