Scenario Solution · WEB-ITDR
AI agent and
non-human access governance
AI assistants, agents, RPA robots, scripts and service accounts reach business systems carrying a person's credentials, so the identity system only ever sees a normal employee login. This solution identifies that access, attributes it to a responsible person, scopes what it may reach, and keeps watching.
The Problem
Automated access arrives holding a person's credential
AI assistants, agents, RPA robots, scripts and service accounts all reach business systems, using credentials an employee authorised or keys that never expire. The identity system sees a normal login, the application sees a normal request, and no layer answers the question of who is actually operating.
Where It Applies
Five kinds of non-human access, five different intents
Start by taking "non-human" apart. Automation differs in origin, in who is accountable for it and in the risk it carries, so it should not be treated the same way — most of it needs registration and scoping, not blocking.
| Category | Typical form | Governance intent |
|---|---|---|
| AI assistants in development | Embedded in an IDE or code platform, reaching repositories, test interfaces and data sources as the developer | Register + scope the applications it may reach |
| Agents authorised by an employee | A program handed cross-system work, with credentials granted by that person | Register + review on key actions |
| Browser-driving tools | Drive a real browser and inherit a login and session already completed | Strict review + behavioural baseline |
| In-house RPA and scripts | Scheduled process robots, cron scripts and monitoring probes | Allowlist registration + credential lifecycle audit |
| External automation and attack tooling | Stuffing, scraping and probing scripts that are not part of any known automation | Judged on behaviour and context |
The table classifies by origin and accountability; it is not a product support list. Automated access is not the same as malicious access — the first four categories all belong in the enterprise, and the point of governance is to give them a register, a responsible owner and a scope, not to block them.
The fifth category is judged on the behaviour and context of the access itself. A tool name, a self-declared client string or a cloud egress range is not enough on its own: the same tunnelling tool and the same cloud egress are used by legitimate business too.
How It Works
Identify, attribute, authorise, monitor
Four steps form one pipeline, and also four deliverables that can be accepted separately: a register, a set of ownership relations, a scope of authorisation, and a line of continuous monitoring. Miss any one and the rest will not hold.
| Signal layer behind the verdict | What this layer observes |
|---|---|
| Network | Client characteristics of the transport handshake, separating browsers from programmatic clients |
| Application | The combination and ordering of request headers, and what the client says it is |
| Device and runtime | Rendering and runtime characteristics, used to recognise headless automation |
| Interaction | Timing relationships between requests, and whether human interaction events exist at all |
| Identity correlation | Employee sessions, devices and authorisation tokens in the same window, used to tie access back to a person |
Several layers are combined because any single one can be evaded or forged; the number of layers is not a claim about accuracy. Which layers are available depends on the deployment — a passive mirror and a reverse proxy see different things, and the visibility of encrypted traffic depends on where TLS terminates. An identification result only becomes actionable when read together with the ownership relation.
Division of Responsibility
Who registers, who authorises, who executes
Governing non-human access cuts across security, business and engineering. When it fails, the cause is usually not technical — it is that nobody agreed who owns which part.
| Step | Web ITDR | Handled by existing systems or teams |
|---|---|---|
| Discovery and identification | Identifies automated access on the path and classifies it | Usually no system owns this — it is the layer added here |
| Register | Supplies the list of identified callers and their access records | Request and approval process, maintained by IT or security |
| Credential and key management | Does not issue, hold or rotate credentials | Key management and IAM: issuance, rotation, revocation |
| Confirming ownership | Provides the correlation evidence and candidate owners | Ownership is confirmed by process, never assigned automatically |
| Authorisation scope | Restricts reachable applications and interfaces by policy | The permission model inside each application still applies |
| Review and approval | Triggers a review and records the outcome | Approval happens in the existing approval or ticketing system |
| Executing a response | Allow, challenge or block on the proxy path | Disabling accounts and revoking tokens run in the identity and key systems |
"Owner" means the person or department accountable for that automated access, confirmed through process. The correlation is evidence for a human to judge, not an automatic determination about an individual; callers that cannot be tied to anyone are listed as such rather than attached to the nearest account.
Rollout
See clearly first, change policy second
The surest way to derail this work is to start with blocking. Move through observation, classification, authorisation and enforcement; each step has something to hand over before you decide whether to tighten.
- Connect passively, staying out of the request path
- Count which automated callers appear, how often, and where
- Produce the first register of non-human access
- Sort callers into the five categories by origin and ownership
- Confirm the owner or requesting department for each
- Flag those that are retired or of unknown origin
- Scope applications and interfaces for registered callers
- Agree which actions require a review
- Get sanctioned automation registered first
- Allow, challenge or block according to policy
- Alert on unregistered callers before acting on them
- Send action records into the audit trail
The order matters: register sanctioned automation before enforcement goes on. Do it the other way round and the first things blocked tend to be the reconciliation robot or the monitoring probe — one business interruption is usually enough to stop the whole programme.
Validation
Validate against two callers you already know
No elaborate attack scenario is needed. Take one piece of sanctioned automation you already run and one AI assistant you already use, and see whether the four questions below have answers.
Agree on the callers taking part, the time window and the acceptance criteria before validation starts. No identification-rate figures are reported until it is complete. What the demonstration environment shows is a product demonstration scenario, used to explain how the grounds support a verdict; it is not any customer's actual incident record.
Expert Consultation
Take one automated caller from your environment and walk it through
Tell us which AI tools, RPA robots and service accounts are already in use, and we will show the signals behind the verdict, how the caller is tied back to a person, and how the authorisation policy would read:
Signals behind the verdict
Explained against tools you actually run
Attribution review
How automated access is tied to a person
Draft authorisation policy
Register, review, authorise, block
Scan with Feishu to consult