Access and activity

Collecting files, browsing a host's file system and running console commands are hands-on operations. The Access tab decides who may do them on a fleet's endpoints, and the Activity tab records who did — including attempts that were refused.

Beta

This feature is currently rolling out and may not be enabled for your organization.

Both tabs work on one fleet at a time, and both are for fleet admins — people with the admin role on the fleet's connection. Everyone else sees Only fleet admins can manage access or Only fleet admins can see this fleet's activity.

How endpoint access works

People reach a fleet's endpoints through their role on the connection, plus anything a fleet admin grants on the Access tab — for the whole fleet or for one tag. The tab's How endpoint access works section says the same thing in the app.

• Connection roles (viewer, editor, admin) mostly come from organization membership and are managed through connection sharing, not here. Connection admins can already do everything a responder can.
• Responder is the hands-on role: collect files, browse files and run console commands — without making someone a connection admin.
• You grant access on the whole fleet (responder only) or on a tag: "Dana is a responder on everything tagged finance".
• Grants only ever add access. There is no "everything except".
• A grant belongs to one fleet and one tag. The same tag on another fleet is a separate grant.

What each role can do

Each role includes everything the one before it has.

What they can do	Viewer	Operator	Responder
See endpoints and their details	Yes	Yes	Yes
Read endpoint logs	—	Yes	Yes
Tag endpoints	—	Yes	Yes
Run collections	—	Yes	Yes
Collect files	—	—	Yes
Browse files	—	—	Yes
Run console commands	—	—	Yes

Add a fleet-wide responder

Fleet-wide responders can collect files, browse files and run console commands on every endpoint in the fleet.

1. Open Endpoints, choose the fleet, and open the Access tab.
2. Under Fleet-wide responders, click Add responder.
3. Choose a member of the organization that owns the fleet. Search by name or email.
4. Click Grant access.

Only members of the organization that owns the fleet can be picked. If someone is missing, add them to the organization first.

Grant access by tag

Access by tag gives someone a role on just the endpoints carrying a particular tag. Endpoints tagged later are included automatically.

1. Under Access by tag, click Grant access by tag.
2. Choose an access-bearing tag. Each tag shows how many endpoints carry it.
3. Choose a member.
4. Choose a role — Viewer, Operator or Responder.
5. Click Grant access.

To give another person a role on a tag that already has grants, click Add person on that tag's group.

Access-bearing tag folders

Only tags in a tag folder marked Access-bearing can carry access. That is deliberate: putting such a tag on an endpoint gives the tag's people access to that endpoint, so these tags are kept apart from everyday tags. Ordinary tags never affect access.

Two things follow:

• Only people who manage endpoint access can assign these tags to endpoints. If anyone else tries, the endpoint is not tagged and Huntbase says: "This tag grants endpoint access, so only someone who manages endpoint access can assign it."
• An organization admin turns the setting on, per folder, under Settings → Tags. See Organization management. If no folder is access-bearing yet, the Access tab says No access-bearing tag folder yet, and organization admins get a Manage tag folders button.

warning

Turning the setting off on a folder deletes access. The confirmation reads: "Every endpoint-access grant on this folder's tags will be deleted, on every fleet. People who reach endpoints only through those tags lose that access straight away." Turning it back on later does not bring the grants back — they have to be granted again.

Revoke access

Click Revoke next to a person, then Revoke access to confirm. They stop holding that role on that fleet or tag. Access they have through their connection role or another grant is not affected.

Dormant grants

Dormant grants lists grants that sit on tags that are no longer in an access-bearing folder. They give nobody access today. They stay listed so you can see what was left behind and remove it with Revoke.

When you can't change access

What you see	Why
Only fleet admins can manage access	You are not an admin of this fleet's connection. Ask one of its admins.
This fleet is shared — access is managed by Huntbase	The fleet serves more than one organization. Contact Huntbase support.
"That person isn't a member of the organization that owns this fleet."	Add them to the organization first, then grant access.
"That tag can't carry access…"	The tag isn't in an access-bearing tag folder owned by the fleet's organization.

Read the Activity tab

The Activity tab is the fleet's audit trail: every hands-on operation on its endpoints, newest first — including attempts that were refused. Console output and file contents are never recorded. The text of a console command and the path of a file are.

Column	What it tells you
When	When it happened.
Who	The person — or Scout, A watcher, A schedule or An API key, with "on behalf of" and the person it acted for. Actions by Huntbase staff read Huntbase staff.
What	The operation in plain words, such as "Collected /var/log/auth.log from web-01". An operation that did not complete reads "Tried to …", because an attempt is not an outcome.
On what	The endpoint, the number of endpoints, or the fleet.
Outcome	See the table below.

Expand a row for the full record, including what allowed the operation and where it was started from. Export this page downloads the rows on the current page with the current filters.

Outcomes

Outcome	Meaning
Completed	The operation finished.
Failed	The operation was allowed but did not succeed.
Denied	The attempt was refused — the person lacked the permission.
Attempted — outcome unknown	The operation was started, but nothing was recorded about how it ended. It may or may not have happened.
Accepted	The operation was accepted; no result was recorded.

Filter the trail

Filter	Options
Action	All actions, or one action from the groups Files, Console, Access, Install link and Endpoints — for example File collected, Console command run, Access granted, Install link rotated, Endpoint removed.
Outcome	Any outcome, Completed, Failed, Denied, Accepted / outcome unknown.
Done by	Anyone or anything, People, Scout, Watchers, Schedules, API keys.
Time range	Any time, Last 24 hours, Last 7 days, Last 30 days, Custom range.
Person	A member. Person's part then narrows to what they did themselves or what they had done on their behalf.

To answer "what did Scout do for Dana last week?", set Person to Dana, Person's part to had it done on their behalf, and Time range to Last 7 days.

Next steps

• Collect files — what responders can do with files
• Files and console — live sessions and what they record
• Organization management — members, tag folders and storage destinations
• Endpoints overview — fleets, scope and the tabs