By KYN AI Advisory Team — AI implementation specialists, Singapore
A multi-cloud audit trail breaks because each platform names the actor differently. AWS logs a role session, Azure logs a service principal or user object, and an on-prem directory logs a bind. Without a table that maps all of them to one person or agent, you cannot answer "who did this?" in one query. More logging does not fix this. Identity correlation does.
Why is more logging not the fix?
Every platform already logs. AWS CloudTrail records API activity in an AWS account. Azure Monitor collects activity and resource logs in Azure. Servers on-prem write syslog or directory logs.
The gap is not volume. It is that each record names the actor in a different vocabulary, so the three logs cannot be joined. An auditor asks "show everything this person did last quarter" and you get three exports and a spreadsheet.
What are the three credential models?
| Platform | Typical actor | What the log shows | |---|---|---| | AWS | IAM role assumed by a user or service | Role ARN and a session name, which may be generic | | Azure | Service principal or user in Microsoft Entra ID | Object ID and app ID | | On-prem | LDAP or Kerberos account | Distinguished name or principal, often a shared service account |
Each model is sound alone. The failure is at the seams, especially where one automation uses a shared key to cross between them.
Where does the audit trail break?
These are patterns, not reports of a specific incident.
- Shared logins. An ops agent uses one service account on three systems. Every action looks like the same actor.
- Role chaining. A person assumes a role, which assumes another. The final log line names the last role only.
- Long-lived keys. A key created for a script outlives the person who made it. Nobody owns it.
- Clock and format drift. Timestamps differ in zone and precision, so events cannot be ordered.
- Retention mismatch. One log is kept 90 days, another a year. The gap appears only during the audit.
What does manual correlation cost?
During an incident, an engineer exports three logs, matches identities by hand and builds a timeline. That is hours of senior time at the moment speed matters. During an audit it repeats for every sampled event. The cost is not the tooling. It is the time, and the events you cannot attribute at all.
What does a unified identity chain need?
- One identity per person and per agent. Named accounts through the cloud provider's identity service. No shared logins.
- A mapping table. Person or agent ID, mapped to the AWS role session, the Azure object and the directory account.
- Session naming. Each assumed role carries the person's ID in the session name, so the log line names a human.
- Short-lived credentials. Prefer temporary credentials over long-lived keys.
- One timeline. Ship all logs to one store, in UTC, with a common actor field.
- Actor on every action. Application-level logs record who or what acted, including agents.
- Retention set once. The same minimum across all sources.
How do you close the gap in practice?
Start with an inventory. List every credential used by a person, a script or an agent, and its owner. Delete what has no owner. Replace shared logins with named ones. Then build the mapping table and test it: pick ten random events and trace each to a person in under five minutes. If you cannot, the chain is not complete.
For agents, give each its own restricted account. An agent that acts through a person's login makes the log lie.
What does a blind spot look like in an incident?
This is an illustrative scenario, not a report of a real event. An ops agent is investigating a suspected credential compromise.
| Time (UTC) | System | What the log says | What a human sees | |---|---|---|---| | 02:14 | AWS | An assumed-role session starts under a role used by an automation | Nothing links it to a person | | 02:28 | Azure | A service principal signs in | Different identifier, different format | | 02:48 | On-prem | A directory bind succeeds from a service account | A third identifier |
To an investigator these may be one continuous chain of access. To the three systems they are three unrelated events. Proving the link by hand takes time at the moment when time matters most.
An audit has the same shape on a slower clock. An auditor asks for every access to a given resource across the whole environment for a quarter. If the answer must be assembled by hand from three formats, two things can go wrong. A gap in the manual match can be read as a gap in access, or the reverse. Either can fail the audit for reasons unrelated to whether access was well controlled.
How should the correlation layer work?
Do not collapse the job into one step. Separate it into four stages, so that errors surface where they are cheapest to catch.
- Collection. Pull raw events from AWS, Azure and the on-prem directory without interpreting them.
- Normalisation. Convert time to UTC and put identity fields into one shape: actor, source system, action, resource, result.
- Correlation. Match events to a person or agent using the mapping table and the session name. Score each match as certain or uncertain.
- Review. Send uncertain matches to a named person.
Bias the correlation toward flagging. A wrong match in a security audit is worse than an open gap, because it creates false confidence at the moment confidence matters. This is the same rule used in payment reconciliation: a false match is worse than a missed one.
The same discipline applies to normalising time. Record every event in UTC with millisecond precision where the source allows. Keep the source's original timestamp as well, so that you can show an auditor the raw value and the converted one.
What should the mapping table hold?
A small table does most of the work. One row per identity.
| Field | Example | |---|---| | Identity ID | A person's staff ID or an agent's name | | Type | Person, agent or service | | Owner | The accountable person | | AWS | Role names and the session-name pattern | | Azure | Object ID and app ID | | On-prem | Directory account or principal | | Status | Active, suspended, removed | | Last review | Date |
Three rules keep it honest.
- One owner per row. An identity with no owner is a finding.
- Update on joiners and leavers. Add the row on the day access is granted and set the status on the day it ends.
- No shared rows. If two people use one account, split it before you build the table.
The table is only as good as the discipline around it. A stale table gives a confident wrong answer.
How do you test the chain?
Run a monthly test with real events.
- Pick ten random events from the last 30 days across the three systems.
- For each, find the person or agent responsible using only the unified store and the mapping table.
- Time it. A target is under five minutes per event.
- Record any event you cannot attribute and the reason: shared login, missing session name, missing mapping, clock drift.
- Fix the cause, not the one event.
Add one hostile case each quarter. Have an engineer assume a role and then act in a second system, and check that the chain shows one person across both.
What about agents and automations?
Agents make attribution harder because they act fast and in many systems.
- Give each agent its own restricted account, not a person's login.
- Name its sessions with the agent ID, so the cloud log names the agent.
- Record the human approver separately for any action that waits for a person.
- Log the agent's inputs and outputs in the application, not only the platform's API calls.
- Make read and write accounts separate, so a reporting agent cannot change anything.
If an agent acts through a staff login, the log says the person did it. That is a false record, and it may break your obligations to show who accessed personal data.
How does this apply to a small operations team?
A small team does not need a large tool. It needs five things done well.
- An inventory of credentials, each with an owner.
- Named accounts, with no shared logins.
- Short-lived credentials for anything automated.
- One log store, one time zone, one actor field.
- The monthly ten-event test.
A larger security information and event management product can come later, once the basics produce clean data. Putting a large tool on top of unmapped identities only moves the confusion to a dashboard.
What does the plan cost in effort?
Illustrative estimate for an SME with one AWS account, one Azure tenant and one directory.
| Task | Effort | Output | |---|---|---| | Credential inventory | A few days | A list with owners; orphaned credentials removed | | Named accounts and session naming | A week or two | No shared logins; actor visible in logs | | Mapping table and normalised store | A week or two | One query answers "who did this?" | | Retention alignment | A day | The same minimum period across sources | | Monthly test | A few hours each month | A record of attribution speed and gaps |
The numbers will change with your estate. The order should not: inventory, then identity, then the table, then the store.
Where KYN fits
KYN builds operations systems in a cloud account in the client's name. Access uses named accounts through the cloud provider's identity service, with no shared logins, one restricted account per user per session, and separate restricted accounts for agents. Every action is logged with the actor, and outbound messages, money, filings and deletions wait for a named person. The database uses row-level security.
The first 14 days are a review that includes an inventory of credentials in your stack. See security and operations. For the control side, read the AI agent security checklist.
Frequently asked questions
Do I need a SIEM to correlate multi-cloud identities?
Not always. A SIEM helps at scale. For an SME, a mapping table plus one log store with a common actor field answers most audit questions at lower cost.
Why do shared service accounts break auditing?
They hide which person or agent acted. The log shows the account, not the cause. Named accounts per person and per agent restore attribution.
How often should credentials be reviewed?
Review owners and access at least quarterly, and on every staff departure. Prefer short-lived credentials so that forgotten keys expire on their own.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
