Before an agent reaches your systems, how should access and audit be designed?

An agent cannot inherit an ordinary employee account

An ordinary application waits for a user to click through. An agent can call several tools in sequence, so one instruction may read a file, change its contents and send it outward. Permission for each individual action does not make the sequence correct.

Authorisation has to state the executing identity, the task it belongs to, the actions it may take, and which operations must stop and wait for a person.

Permissions follow the task

Its own identity

When several agents share an administrator account or an employee's private key, an administrator cannot tell where an operation came from. Every executor is authorised and suspended on its own, with a named owner.

Project scope

An agent reaches files, repositories and business interfaces after it enters a specific project. When the project ends, an administrator withdraws resources by project rather than hunting for scattered grants.

Action-level permission

Read, modify, delete and send outward are granted separately. An agent that proposes changes does not thereby gain the right to merge into a production branch.

Sensitive operations

Production changes, handling of personal data, large resource spend and outbound communication can require approval or human takeover. The confirmation has to happen before the action; a notification afterwards cannot prevent the mistake.

Credential custody

Keys stay with the platform or a dedicated credential system and are supplied at execution time. That keeps them out of prompts, files and logs, and lets them be revoked when someone leaves or a project closes.

Records have to reconstruct what happened

At minimum: who started it, which project it belonged to, the models and tools used, the resources reached, the key actions, the resource spend, and any failures and retries.

Logs can contain sensitive data themselves. Administrators should limit who may read them and set a retention period and masking rules. In mainland China the floor is set by law: article 23 of the Cybersecurity Law requires network operators to retain the relevant network logs for no less than six months. How the spend side is attributed is covered in managing multi-model usage, quota and cost.

Check before go-live

• No agent runs on a shared administrator account.
• Every agent has an owner and a way to switch it off.
• Read, write, delete and outbound send are granted separately.
• Production changes and outbound sends require human confirmation.
• Keys do not appear in prompts or working files.
• Failures, retries and human takeover can all be looked up.
• Logs have masking rules and a retention period.
• Permissions and resources can be withdrawn together when a project ends.

Common questions

Can an agent run on an employee or administrator account?

It should not. When several agents share an administrator account or a private key, an administrator cannot tell where an operation came from. Authorise and suspend each executor on its own, with a named owner.

Which operations should wait for human confirmation?

Production changes, handling of personal data, large resource spend and outbound communication. The confirmation has to happen before the action, because a notification afterwards cannot prevent the mistake.

What does an execution record have to contain?

Who started it, the project, the models and tools, the resources reached, the key actions, the resource spend, and any failures and retries. Logs may hold sensitive data, so limit who can read them and set retention and masking rules.

Where should keys be kept?

With the platform or a dedicated credential system, supplied at execution time, so they stay out of prompts, files and logs and can be revoked when someone leaves or a project closes.