[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fUueeSYttdatMY5eQzM_0JyoOn98LdGWy_JkW2xoFbd4":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":7,"kindOverride":8,"slug":9,"title":10,"description":11,"bodyMarkdown":12,"bodyHtml":13,"author":14,"date":15,"createdAt":16,"topics":17,"image":27,"hasDownload":28,"fileName":7,"youtubeId":29},"503","3F29FCB9-A392-DD40-9D71-BB496F65F6E5","","article","your-next-user-might-be-an-ai-agent-the-new-identity-problem-for-businesses","Your Next User Might Be an AI Agent: The New Identity Problem for Businesses","AI agents are moving beyond simple chatbots and becoming digital workers that can access databases, call APIs, update records, send emails, and perform business tasks autonomously. This creates a new security challenge: how should businesses identify, authenticate, authorize, monitor, and eventually disable an AI agent?\n\nAs companies deploy more autonomous agents, treating them like ordinary API clients or giving them broad service-account permissions can create unnecessary risk. The solution is to give every agent a controlled identity, limited permissions, short-lived credentials, and a complete audit trail.","AI Agents Are Becoming Digital Identities\n\nFor years, enterprise identity management was mainly about people and applications.\n\nA company might have:\n\nEmployee\n   ↓\nUser Account\n   ↓\nPermissions\n   ↓\nBusiness Applications\n\nApplications also have service accounts and API credentials.\n\nBut AI agents introduce something different.\n\nAn AI agent can make decisions and perform actions on behalf of a business:\n\nAI Agent\n   ↓\nAPI\n   ↓\nCRM\n   ↓\nUpdate Customer\n\nOr:\n\nAI Agent\n   ↓\nFileMaker\n   ↓\nCreate Survey\n   ↓\nSend Notification\n\nThe agent is no longer just software waiting for a developer to tell it exactly what to do. It can determine which tool to use and what action to take based on the user's request and the information it receives.\n\nThat means the agent itself needs to become a controlled identity.\n\nWhy Traditional API Access Isn't Enough\n\nA common way to connect an AI agent to a business system is to give it an API key.\n\nFor example:\n\nAI Agent\n   ↓\nAPI Key\n   ↓\nFileMaker API\n\nThis can work technically, but the security question is:\n\nWhat exactly can that API key do?\n\nIf the key has broad access, the agent may be able to:\n\nRead customer information\nModify records\nCreate invoices\nSend emails\nChange settings\nDelete data\n\nThe problem isn't necessarily that the AI is malicious.\n\nThe problem is that one compromised or incorrectly behaving agent now has too much authority.\n\nThe Principle of Least Privilege\n\nA better approach is to give an AI agent only the permissions required for its specific job.\n\nFor example, an HR survey agent might need:\n\n✓ Create survey\n✓ Read survey questions\n✓ Read survey results\n\n✗ Delete users\n✗ Modify billing\n✗ Change user permissions\n✗ Delete database records\n\nThis is the same principle used in traditional cybersecurity:\n\nGive an identity the minimum access required to perform its job.\n\nBut now that principle needs to be applied to AI agents as well.\n\nEvery Agent Should Have Its Own Identity\n\nInstead of using one shared API account:\n\nAI Agent\n   ↓\nadmin@example.com\n   ↓\nEverything\n\nuse a dedicated identity:\n\nSurvey Agent\n   ↓\nsurvey-agent-ID\n   ↓\nSurvey permissions only\n\nAnother agent could have a completely different identity:\n\nInvoice Agent\n   ↓\ninvoice-agent-ID\n   ↓\nInvoice permissions only\n\nThis makes it easier to answer an important question:\n\nWhich agent performed this action?\n\nWhat Happens When an Agent Makes a Mistake?\n\nImagine an AI agent receives this request:\n\n\"Update this customer's information.\"\n\nThe agent calls an API and changes the record.\n\nLater, someone asks:\n\n\"Who changed this customer's address?\"\n\nIf all actions use the same API account, the audit log might only show:\n\nadmin → Customer updated\n\nThat's not enough.\n\nWith dedicated agent identities:\n\n2026-09-28 10:42\nAgent: CustomerSupportAgent\nAction: UpdateCustomer\nCustomer: 10452\nFields: Address\nRequest ID: 82931\n\nNow the organisation can trace the action back to the specific agent and workflow.\n\nAI Agents Need an Audit Trail\n\nAn AI agent should not operate like a black box.\n\nImportant actions should be logged:\n\nAgent identity\n↓\nUser request\n↓\nDecision \u002F intent\n↓\nTool called\n↓\nParameters\n↓\nResult\n↓\nFinal action\n\nFor example:\n\nUser:\n\"Create a survey for the safety team.\"\n\n        ↓\n\nAI Agent:\nCreateSurvey\n\n        ↓\n\nPermission Check:\nAllowed\n\n        ↓\n\nFileMaker:\nCreate Survey\n\n        ↓\n\nAudit Log:\nSurvey #452 created\n\nThis makes troubleshooting and security investigations much easier.\n\nShort-Lived Credentials\n\nAnother important concept is credential lifetime.\n\nImagine an agent gets an API credential today and keeps it forever.\n\nIf that credential is compromised, the attacker may continue using it long after the original task has finished.\n\nA safer approach is:\n\nAgent requests access\n        ↓\nShort-lived credential\n        ↓\nPerform task\n        ↓\nCredential expires\n\nThis limits the potential damage.\n\nThe same principle can be applied to temporary agents created for specific projects or workflows.\n\nWhat Happens When an AI Agent Is No Longer Needed?\n\nBusinesses already have an established process for employees:\n\nEmployee leaves\n      ↓\nDisable account\n      ↓\nRemove permissions\n\nAI agents need the same lifecycle management.\n\nFor example:\n\nCreate Agent\n     ↓\nAssign Identity\n     ↓\nAssign Permissions\n     ↓\nMonitor Usage\n     ↓\nReview Permissions\n     ↓\nDisable Agent\n     ↓\nRevoke Credentials\n\nOtherwise, organisations can end up with unused AI agents that still have access to business systems.\n\nAI Agent + FileMaker Example\n\nThis is particularly relevant when connecting AI to FileMaker.\n\nA risky architecture could look like:\n\nBetterForms\n     ↓\nAI Agent\n     ↓\nFull FileMaker API Access\n     ↓\nDatabase\n\nA safer architecture would be:\n\nBetterForms\n     ↓\nAI Agent\n     ↓\nAgent Identity\n     ↓\nPermission Check\n     ↓\nApproved Tool \u002F FileMaker Script\n     ↓\nValidation\n     ↓\nFileMaker\n     ↓\nAudit Log\n\nFor sensitive operations:\n\nAI Agent\n     ↓\nSuggest Action\n     ↓\nValidation\n     ↓\nHuman Approval\n     ↓\nFileMaker\n\nFor example, an AI agent could suggest creating an invoice, but the actual financial action could require approval.","\u003Cp>AI Agents Are Becoming Digital Identities\u003C\u002Fp>\n\u003Cp>For years, enterprise identity management was mainly about people and applications.\u003C\u002Fp>\n\u003Cp>A company might have:\u003C\u002Fp>\n\u003Cp>Employee\n   ↓\nUser Account\n   ↓\nPermissions\n   ↓\nBusiness Applications\u003C\u002Fp>\n\u003Cp>Applications also have service accounts and API credentials.\u003C\u002Fp>\n\u003Cp>But AI agents introduce something different.\u003C\u002Fp>\n\u003Cp>An AI agent can make decisions and perform actions on behalf of a business:\u003C\u002Fp>\n\u003Cp>AI Agent\n   ↓\nAPI\n   ↓\nCRM\n   ↓\nUpdate Customer\u003C\u002Fp>\n\u003Cp>Or:\u003C\u002Fp>\n\u003Cp>AI Agent\n   ↓\nFileMaker\n   ↓\nCreate Survey\n   ↓\nSend Notification\u003C\u002Fp>\n\u003Cp>The agent is no longer just software waiting for a developer to tell it exactly what to do. It can determine which tool to use and what action to take based on the user's request and the information it receives.\u003C\u002Fp>\n\u003Cp>That means the agent itself needs to become a controlled identity.\u003C\u002Fp>\n\u003Cp>Why Traditional API Access Isn't Enough\u003C\u002Fp>\n\u003Cp>A common way to connect an AI agent to a business system is to give it an API key.\u003C\u002Fp>\n\u003Cp>For example:\u003C\u002Fp>\n\u003Cp>AI Agent\n   ↓\nAPI Key\n   ↓\nFileMaker API\u003C\u002Fp>\n\u003Cp>This can work technically, but the security question is:\u003C\u002Fp>\n\u003Cp>What exactly can that API key do?\u003C\u002Fp>\n\u003Cp>If the key has broad access, the agent may be able to:\u003C\u002Fp>\n\u003Cp>Read customer information\nModify records\nCreate invoices\nSend emails\nChange settings\nDelete data\u003C\u002Fp>\n\u003Cp>The problem isn't necessarily that the AI is malicious.\u003C\u002Fp>\n\u003Cp>The problem is that one compromised or incorrectly behaving agent now has too much authority.\u003C\u002Fp>\n\u003Cp>The Principle of Least Privilege\u003C\u002Fp>\n\u003Cp>A better approach is to give an AI agent only the permissions required for its specific job.\u003C\u002Fp>\n\u003Cp>For example, an HR survey agent might need:\u003C\u002Fp>\n\u003Cp>✓ Create survey\n✓ Read survey questions\n✓ Read survey results\u003C\u002Fp>\n\u003Cp>✗ Delete users\n✗ Modify billing\n✗ Change user permissions\n✗ Delete database records\u003C\u002Fp>\n\u003Cp>This is the same principle used in traditional cybersecurity:\u003C\u002Fp>\n\u003Cp>Give an identity the minimum access required to perform its job.\u003C\u002Fp>\n\u003Cp>But now that principle needs to be applied to AI agents as well.\u003C\u002Fp>\n\u003Cp>Every Agent Should Have Its Own Identity\u003C\u002Fp>\n\u003Cp>Instead of using one shared API account:\u003C\u002Fp>\n\u003Cp>AI Agent\n   ↓\n\u003Ca href=\"mailto:admin@example.com\">admin@example.com\u003C\u002Fa>\n   ↓\nEverything\u003C\u002Fp>\n\u003Cp>use a dedicated identity:\u003C\u002Fp>\n\u003Cp>Survey Agent\n   ↓\nsurvey-agent-ID\n   ↓\nSurvey permissions only\u003C\u002Fp>\n\u003Cp>Another agent could have a completely different identity:\u003C\u002Fp>\n\u003Cp>Invoice Agent\n   ↓\ninvoice-agent-ID\n   ↓\nInvoice permissions only\u003C\u002Fp>\n\u003Cp>This makes it easier to answer an important question:\u003C\u002Fp>\n\u003Cp>Which agent performed this action?\u003C\u002Fp>\n\u003Cp>What Happens When an Agent Makes a Mistake?\u003C\u002Fp>\n\u003Cp>Imagine an AI agent receives this request:\u003C\u002Fp>\n\u003Cp>"Update this customer's information."\u003C\u002Fp>\n\u003Cp>The agent calls an API and changes the record.\u003C\u002Fp>\n\u003Cp>Later, someone asks:\u003C\u002Fp>\n\u003Cp>"Who changed this customer's address?"\u003C\u002Fp>\n\u003Cp>If all actions use the same API account, the audit log might only show:\u003C\u002Fp>\n\u003Cp>admin → Customer updated\u003C\u002Fp>\n\u003Cp>That's not enough.\u003C\u002Fp>\n\u003Cp>With dedicated agent identities:\u003C\u002Fp>\n\u003Cp>2026-09-28 10:42\nAgent: CustomerSupportAgent\nAction: UpdateCustomer\nCustomer: 10452\nFields: Address\nRequest ID: 82931\u003C\u002Fp>\n\u003Cp>Now the organisation can trace the action back to the specific agent and workflow.\u003C\u002Fp>\n\u003Cp>AI Agents Need an Audit Trail\u003C\u002Fp>\n\u003Cp>An AI agent should not operate like a black box.\u003C\u002Fp>\n\u003Cp>Important actions should be logged:\u003C\u002Fp>\n\u003Cp>Agent identity\n↓\nUser request\n↓\nDecision \u002F intent\n↓\nTool called\n↓\nParameters\n↓\nResult\n↓\nFinal action\u003C\u002Fp>\n\u003Cp>For example:\u003C\u002Fp>\n\u003Cp>User:\n"Create a survey for the safety team."\u003C\u002Fp>\n\u003Cpre>\u003Ccode>    ↓\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>AI Agent:\nCreateSurvey\u003C\u002Fp>\n\u003Cpre>\u003Ccode>    ↓\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Permission Check:\nAllowed\u003C\u002Fp>\n\u003Cpre>\u003Ccode>    ↓\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>FileMaker:\nCreate Survey\u003C\u002Fp>\n\u003Cpre>\u003Ccode>    ↓\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Audit Log:\nSurvey #452 created\u003C\u002Fp>\n\u003Cp>This makes troubleshooting and security investigations much easier.\u003C\u002Fp>\n\u003Cp>Short-Lived Credentials\u003C\u002Fp>\n\u003Cp>Another important concept is credential lifetime.\u003C\u002Fp>\n\u003Cp>Imagine an agent gets an API credential today and keeps it forever.\u003C\u002Fp>\n\u003Cp>If that credential is compromised, the attacker may continue using it long after the original task has finished.\u003C\u002Fp>\n\u003Cp>A safer approach is:\u003C\u002Fp>\n\u003Cp>Agent requests access\n        ↓\nShort-lived credential\n        ↓\nPerform task\n        ↓\nCredential expires\u003C\u002Fp>\n\u003Cp>This limits the potential damage.\u003C\u002Fp>\n\u003Cp>The same principle can be applied to temporary agents created for specific projects or workflows.\u003C\u002Fp>\n\u003Cp>What Happens When an AI Agent Is No Longer Needed?\u003C\u002Fp>\n\u003Cp>Businesses already have an established process for employees:\u003C\u002Fp>\n\u003Cp>Employee leaves\n      ↓\nDisable account\n      ↓\nRemove permissions\u003C\u002Fp>\n\u003Cp>AI agents need the same lifecycle management.\u003C\u002Fp>\n\u003Cp>For example:\u003C\u002Fp>\n\u003Cp>Create Agent\n     ↓\nAssign Identity\n     ↓\nAssign Permissions\n     ↓\nMonitor Usage\n     ↓\nReview Permissions\n     ↓\nDisable Agent\n     ↓\nRevoke Credentials\u003C\u002Fp>\n\u003Cp>Otherwise, organisations can end up with unused AI agents that still have access to business systems.\u003C\u002Fp>\n\u003Cp>AI Agent + FileMaker Example\u003C\u002Fp>\n\u003Cp>This is particularly relevant when connecting AI to FileMaker.\u003C\u002Fp>\n\u003Cp>A risky architecture could look like:\u003C\u002Fp>\n\u003Cp>BetterForms\n     ↓\nAI Agent\n     ↓\nFull FileMaker API Access\n     ↓\nDatabase\u003C\u002Fp>\n\u003Cp>A safer architecture would be:\u003C\u002Fp>\n\u003Cp>BetterForms\n     ↓\nAI Agent\n     ↓\nAgent Identity\n     ↓\nPermission Check\n     ↓\nApproved Tool \u002F FileMaker Script\n     ↓\nValidation\n     ↓\nFileMaker\n     ↓\nAudit Log\u003C\u002Fp>\n\u003Cp>For sensitive operations:\u003C\u002Fp>\n\u003Cp>AI Agent\n     ↓\nSuggest Action\n     ↓\nValidation\n     ↓\nHuman Approval\n     ↓\nFileMaker\u003C\u002Fp>\n\u003Cp>For example, an AI agent could suggest creating an invoice, but the actual financial action could require approval.\u003C\u002Fp>\n","Shantanu","2026-09-28",1790578861000,[18,19,20,21,22,23,24,25,26],"AI","AI Agents","Cybersecurity","IAM","Automation","APIs","FileMaker","BetterForms","Data Security","\u002Fapi\u002Fknowledge\u002Fimage\u002F503\u002F?v=4bdb76639dc9",false,null]