A Logged-In User Shouldn't Have to Introduce Themselves to Your Chatbot

While working on an employee management platform, I ran into a problem that looked small at first.

The user was already logged in.

The application knew who they were. Their role was available. Their session was active.

Yet, when they opened the AI assistant and asked about their attendance or leave, the assistant could still ask them to provide their employee ID or name.

Something wasn't connected properly.

The problem wasn't the chatbot's intelligence

My first instinct was to think about how to improve the assistant's instructions.

But the more useful question was: why does the assistant need to ask for information that the application already has?

A chatbot prompt can tell an AI how to behave. It cannot magically give the backend the correct identity, permissions, or database context.

If those things aren't connected properly, even a well-written prompt can produce a frustrating experience.

Three things I started separating

1. Identity: Who is making this request?

This should come from the authenticated session or a verified access token.

The user shouldn't need to introduce themselves every time they open a feature.

2. Authorization: What are they allowed to do?

Knowing someone's identity doesn't mean they can access every resource.

An employee might be allowed to view their own attendance, while an HR administrator may have permission to manage attendance records for multiple employees.

The backend must enforce these permissions. The AI should not decide them on its own.

3. Data scope: Which records should this request use?

Even after identifying the user and checking their permissions, the application must scope the database query correctly.

For example, an employee asking about their leave balance should get data associated with their authenticated employee record—not whichever employee ID happens to appear in a chat message.

These are separate responsibilities. Treating them as one problem creates confusing behavior and can introduce security vulnerabilities.

What the backend should do instead

A simplified version of the flow looks like this:

async def get_my_leave_balance(
    current_user,
    db,
):
    employee = await get_employee_for_user(
        db=db,
        user_id=current_user.id,
    )

    if employee is None:
        raise EmployeeNotFoundError()

    return await get_leave_balance(
        db=db,
        employee_id=employee.id,
    )

This is illustrative pseudocode; the helper functions and exception would need to be implemented in the actual application.

The important part is where employee.id comes from: a trusted relationship between the authenticated user and their employee record.

The client or chatbot shouldn't be able to choose another employee's identity just by supplying a different ID.

For administrative actions, the backend would also need to verify the user's role and the specific permission required for that operation.

The bigger lesson

Building AI features has made one thing particularly clear to me: adding an AI model doesn't remove the need for good backend architecture.

Authentication, authorization, data access, and business rules still need to work correctly.

The AI can help interpret a request. The application must determine whose request it is, what that person can access, and which data the answer should be based on.

That distinction matters even more when the assistant can do things rather than simply answer questions.

I'm still learning, building, and finding these gaps in real projects. And sometimes, the most useful engineering lesson comes from a feature that technically works but still behaves in a way that makes no sense to the user.

My takeaway: Don't ask the user to repeat information your system should already know. Pass the right context through the right layers, and enforce the important rules on the backend.

I'd be interested to hear how other developers handle authenticated user context in AI assistants, especially in applications with multiple roles and organizations.