Endpoint security feeds

Your endpoint sensor already watches every process on every laptop. If you are streaming it to your own bucket or storage container, Trefur can read that stream and keep the slice that belongs to coding agents — what claude, cursor or codex and their children actually did on the machine.

Trefur reads from your storage. It is not a second sensor, it does not install anything on the endpoint, and it never holds a static key to your cloud account.

The three feeds

All three are added under Inventory → Discovery, on the Connectors tab, under the platform Endpoint detection (EDR). Pick your vendor from the connector types offered there. Each one takes a connector slot on your plan, the same as any other connector.

CrowdStrike Falcon Data Replicator and SentinelOne Cloud Funnel

Both are S3 feeds and connect the same way: you create a read-only role in your own AWS account, and Trefur assumes it. Static access keys are not accepted on this path — role assumption is the only option.

1. Create the role

Trefur shows you two values for your workspace on the AWS connection screen: the Trefur AWS principal and a per-workspace External ID. Set your role's trust policy to allow that principal, gated on that External ID:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "<TREFUR_AWS_PRINCIPAL_FROM_DASHBOARD>" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "<EXTERNAL_ID_FROM_DASHBOARD>" }
    }
  }]
}

2. Grant it the reads

{
  "Version": "2012-10-17",
  "Statement": [
    { "Sid": "TrefurListBucket",
      "Effect": "Allow", "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::<your-edr-bucket>" },
    { "Sid": "TrefurGetObjects",
      "Effect": "Allow", "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::<your-edr-bucket>/*" }
  ]
}

Only if you are going to point Trefur at a notification queue, add this statement as well. Leave it out otherwise — an unused queue permission is a permission you have to explain later.

{
  "Sid": "TrefurReadQueue",
  "Effect": "Allow",
  "Action": ["sqs:ReceiveMessage", "sqs:DeleteMessage"],
  "Resource": "arn:aws:sqs:<region>:<account>:<your-queue>"
}

3. Fill in the connector

The region is required by name — a connector saved with only a generic region key is reported as missing credentials before it ever runs. Requests go to the regional, path-style S3 endpoint, and a notification queue must live on that region's SQS host.

Notifications, or listing

• With a queue URL, Trefur long-polls it and reads only the objects it is told about. Messages are acknowledged after the pull has read the objects they named, and a pull that fails acknowledges nothing, so the whole batch is redelivered rather than skipped. Messages that are not object-created events for your bucket and prefix are left on the queue and counted — configure your own redrive policy if you want them moved to a dead-letter queue.
• Without one, Trefur lists the bucket under the prefix and reads forward from the last key it read. This relies on the vendor's key layout being time-ordered, which both feeds' default layouts are.

Microsoft Defender for Endpoint

Point Defender's streaming API at a storage account, then give Trefur a container SAS URL with read and list permission, scoped to that one container and with an expiry you choose.

The SAS URL is the credential, and Trefur handles it as one on every surface you can read: it is masked wherever the connector is read back, and stripped from error messages and logs, so a signature cannot leak through a failure or a support ticket. Be exact about what that is — masking is a read-side control, not encryption at rest. Supply the URL as a linked credential rather than as connector configuration if you want it held in the credential store.

The URL must be:

• https, on an Azure Storage host;
• of the form https://<account>.blob.core.windows.net/<container>?<sas> — one container, not the account root;
• carrying a SAS signature.

Anything else is refused with the reason — but note when: the shape is checked on the connector's first scan or pull, not at the moment you save it. A malformed URL saves cleanly and then shows up as the connector's last error. Run a connectivity scan after saving rather than assuming a clean save means a good credential.

Trefur reads the hourly files Defender writes and resumes a file that is still growing from where it stopped, so an hour is not re-read from the beginning every pull. There is no queue or notification mode for this feed.

Setting it up: the SAS URL is not a field in the discovery wizard, by design — it is a bearer token in a URL and arrives from a linked credential. Create the credential carrying the container SAS URL and link it to the connector. Everything else about the Defender connector, including the optional agent process names, is in the wizard.

What Trefur keeps

An endpoint feed is every process on every device. Trefur wants the few thousand events a day that belong to an agent, so records are filtered at the parse boundary, before anything is built or stored.

A record is kept when the process behind it — or that process's parent, or its grandparent — is a known agent process, or when the process is one Trefur already recognised as an agent process on that device. Recognition is remembered in the connector's own checkpoint, so it carries from one pull to the next rather than resetting; the set is bounded in size and entries age out. The default names:

claude, claude-code, cursor, cursor helper, cursor helper (plugin),
codex, gemini, openhands, aider, goose, amp, devin

Names are compared on the image name alone — directory stripped, case folded, .exe removed — so C:\\…\\node.exe, /usr/local/bin/node and node are the same process name. Setting Agent process names on the connector replaces the list above rather than adding to it.

Of an agent's activity, Trefur maps these event kinds:

• Process creation → an exec_subprocess step.
• Network connection → net_connect, with destination address, port and protocol.
• DNS request → dns_query.
• File written, renamed or deleted → a deletion becomes file_delete; every other file operation, renames included, becomes file_write. Both carry the path, and the vendor's own verb is kept alongside so a rename is still identifiable as one.

Event kinds a vendor emits that are not in that list — registry writes, for example — are dropped rather than guessed at. Every pull logs its own denominator: objects read, compressed bytes, lines seen, lines parsed, records kept, records dropped, malformed lines, queue messages rejected, and runs built. A silent feed and a heavily filtered feed cannot be confused. The number of unmapped event kinds is not one of those figures: it shows up as the gap between lines seen and lines parsed.

What a run and a step look like

One run per agent session the sensor saw on a device. Its name is the agent's own program name (claude, cursor); its window runs from the first kept event to the last; its status is always completed, because a sensor reports what happened rather than whether the agent thought it succeeded. It is marked as observed — this is evidence Trefur was given, not telemetry an SDK emitted — and its source is recorded as an OS sensor, with the vendor named.

One step per kept event, in time order, carrying what the sensor reported about that event. Run and step identities are derived from the vendor's own event and device identifiers, so re-reading an object after a failure updates the same run instead of creating a duplicate.

What is stored, and what is never stored

• Never stored: the machine name. It is used only to derive a keyed, per-workspace digest that lets two views of the same machine be brought together; the name itself never enters a run, a step or a finding.
• Content, governed by your redaction setting: command lines, file paths and DNS names. These are customer content and are withheld unless your workspace has opted that key into full content — see configuration.
• Structural, always kept: process identifiers and names, destination address, port and protocol, the file operation, the vendor and device identifiers, and the host digest.
• Also kept when the vendor supplies it: the OS account the process ran as.

Intent and effect

A sensor sees what a process did. A runtime hook sees what an agent meant to do. Trefur brings the two together: where both views of the same machine exist, the run page shows the linked runs from the other side, and Trefur raises a finding when an agent process on a covered host is not accounted for by any session, or when a host produces agent activity with no runtime coverage at all. See linked runs.

Polling

Each connector polls on its own schedule — every 60 minutes by default, configurable per connector. A pull is bounded by objects, bytes and time; when a bound stops it, the page is kept, the checkpoint advances to exactly where it stopped, and the next pull resumes there. A pull that fails before reading anything is an error and leaves the checkpoint untouched, so the objects are read again rather than skipped. Five consecutive failures disable the connector and surface the last error.

Limits

• Trefur reads your storage. It does not call the vendor's management API, does not enroll sensors, does not change policy and cannot act on an endpoint.
• Only the event kinds listed above are mapped. Anything else in the feed is counted and dropped.
• Only what an agent did is kept. A machine's other activity is never stored, so these connectors are not a general endpoint-telemetry archive.
• An agent running inside a container is not linked to a session seen on the host; the two are reported from different environments.
• A connectivity scan on these connectors returns no discovered agents by design — agents appear once telemetry has been pulled, not at scan time.
• Without the listing prefix matching the vendor's layout, listing mode can read more objects than it needs; a notification queue avoids that.
• The Defender connector takes its SAS URL from a linked credential (see above), and there is no Entra or OAuth alternative to the SAS URL.
• A connector's credentials and URLs are checked on its first scan or pull, not when you save it. A bad value is reported as the connector's last error rather than refused at the keyboard.
• A pull that stops on its own size or time budget can acknowledge a queue message whose later objects it had not reached; those objects are not redelivered. This only affects notifications that name several objects at once, and only the listing mode is unaffected by it.
• There is no backfill command. Trefur reads forward from the first pull; history already in the bucket is read only if it still sorts after the connector's starting point.