Your Next User Might Be an AI Agent: The New Identity Problem for Businesses

AI Agents Are Becoming Digital Identities

For years, enterprise identity management was mainly about people and applications.

A company might have:

Employee ↓ User Account ↓ Permissions ↓ Business Applications

Applications also have service accounts and API credentials.

But AI agents introduce something different.

An AI agent can make decisions and perform actions on behalf of a business:

AI Agent ↓ API ↓ CRM ↓ Update Customer

Or:

AI Agent ↓ FileMaker ↓ Create Survey ↓ Send Notification

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.

That means the agent itself needs to become a controlled identity.

Why Traditional API Access Isn't Enough

A common way to connect an AI agent to a business system is to give it an API key.

For example:

AI Agent ↓ API Key ↓ FileMaker API

This can work technically, but the security question is:

What exactly can that API key do?

If the key has broad access, the agent may be able to:

Read customer information Modify records Create invoices Send emails Change settings Delete data

The problem isn't necessarily that the AI is malicious.

The problem is that one compromised or incorrectly behaving agent now has too much authority.

The Principle of Least Privilege

A better approach is to give an AI agent only the permissions required for its specific job.

For example, an HR survey agent might need:

✓ Create survey ✓ Read survey questions ✓ Read survey results

✗ Delete users ✗ Modify billing ✗ Change user permissions ✗ Delete database records

This is the same principle used in traditional cybersecurity:

Give an identity the minimum access required to perform its job.

But now that principle needs to be applied to AI agents as well.

Every Agent Should Have Its Own Identity

Instead of using one shared API account:

AI Agent ↓ admin@example.com ↓ Everything

use a dedicated identity:

Survey Agent ↓ survey-agent-ID ↓ Survey permissions only

Another agent could have a completely different identity:

Invoice Agent ↓ invoice-agent-ID ↓ Invoice permissions only

This makes it easier to answer an important question:

Which agent performed this action?

What Happens When an Agent Makes a Mistake?

Imagine an AI agent receives this request:

"Update this customer's information."

The agent calls an API and changes the record.

Later, someone asks:

"Who changed this customer's address?"

If all actions use the same API account, the audit log might only show:

admin → Customer updated

That's not enough.

With dedicated agent identities:

2026-09-28 10:42 Agent: CustomerSupportAgent Action: UpdateCustomer Customer: 10452 Fields: Address Request ID: 82931

Now the organisation can trace the action back to the specific agent and workflow.

AI Agents Need an Audit Trail

An AI agent should not operate like a black box.

Important actions should be logged:

Agent identity ↓ User request ↓ Decision / intent ↓ Tool called ↓ Parameters ↓ Result ↓ Final action

For example:

User: "Create a survey for the safety team."

    ↓

AI Agent: CreateSurvey

    ↓

Permission Check: Allowed

    ↓

FileMaker: Create Survey

    ↓

Audit Log: Survey #452 created

This makes troubleshooting and security investigations much easier.

Short-Lived Credentials

Another important concept is credential lifetime.

Imagine an agent gets an API credential today and keeps it forever.

If that credential is compromised, the attacker may continue using it long after the original task has finished.

A safer approach is:

Agent requests access ↓ Short-lived credential ↓ Perform task ↓ Credential expires

This limits the potential damage.

The same principle can be applied to temporary agents created for specific projects or workflows.

What Happens When an AI Agent Is No Longer Needed?

Businesses already have an established process for employees:

Employee leaves ↓ Disable account ↓ Remove permissions

AI agents need the same lifecycle management.

For example:

Create Agent ↓ Assign Identity ↓ Assign Permissions ↓ Monitor Usage ↓ Review Permissions ↓ Disable Agent ↓ Revoke Credentials

Otherwise, organisations can end up with unused AI agents that still have access to business systems.

AI Agent + FileMaker Example

This is particularly relevant when connecting AI to FileMaker.

A risky architecture could look like:

BetterForms ↓ AI Agent ↓ Full FileMaker API Access ↓ Database

A safer architecture would be:

BetterForms ↓ AI Agent ↓ Agent Identity ↓ Permission Check ↓ Approved Tool / FileMaker Script ↓ Validation ↓ FileMaker ↓ Audit Log

For sensitive operations:

AI Agent ↓ Suggest Action ↓ Validation ↓ Human Approval ↓ FileMaker

For example, an AI agent could suggest creating an invoice, but the actual financial action could require approval.