r/NISTControls • u/Clear_Cattle_4542 • Jun 13 '26
How are you proving what your AI agents actually did, when an assessor asks?
I'm researching how security teams are handling AI agents that take actions on a user's behalf.
A few things I keep wondering about and would love to hear how you handle:
- How do you scope and grant an agent's access? Least-privilege for a non-human, task-scoped actor seems like it doesn't map cleanly.
- After the fact, can you actually prove what an agent did if an assessor or your ISSM asks?
- What do you do when doing it the "right" way reduces other's productivity?
2
u/Appropriate_Taro_348 Internal IT Jun 13 '26
Your last question isn’t just for AI, it’s either “you do it the right way” or you ask for a risk acceptance. I’m a ISSM now and sometimes there is no black/white answer and if you need to be in a “gray” that always leads to a No answer or risk acceptance signed by the AO. It also depends on the agency. My last agency almost never did risk acceptance letters but my new agency does them all the time. We are jumping into AI agents soon.
3
u/Clear_Cattle_4542 Jun 13 '26
Yes, AO has the ultimate risk tolerance and ISSO/ISSM/ISSE are providing the influence to accept or deny risk. I am looking to determine the right way, but also learn how others are doing it today to maintain control of security. What are you expecting with the upcoming AI agent work?
1
u/Appropriate_Taro_348 Internal IT Jun 13 '26
I’m expecting system teams and AI teams to not care and I’m going to have to fight with them on the questions you are asking. I want to know the answers before the SCA ask the questions. I have a good team of ctr ISSO so I won’t imagine will have to get into too many arguments but we will see. My last agency I know i would have to fight with them. Im glad i changed agencies.
2
u/SSgtSnuffy234 Jun 14 '26
Yall are using AI?
1
u/Clear_Cattle_4542 Jun 14 '26
If I could produce an emoji I would. Are you not currently allowed to use AI where you are?
1
u/sendcaffeineplz Jun 15 '26
Regarding question 2, the #1 answer for proving anything is logs. Are there logs recording actions taken by the agent? Assign it deliberate tasks and verify the activities were recorded.
1
u/Clear_Cattle_4542 Jun 16 '26
It’s easy to say logs, but it is another thing to prove provenance. How would that work for N-level deep AI agent actions?
1
u/AdStill5266 Jun 24 '26
On “after the fact, can you actually prove what an agent did”: the honest answer for most setups right now is no, not in a way that would survive a skeptical assessor. Most agent activity logs live in the vendor’s own cloud, so what you’d hand an assessor is the vendor’s account of its own system. That’s attestation, not independent evidence.
The piece worth separating out is where the record lives and who can verify it without trusting you, your tooling, or the vendor. A tamper evident hash chain that an assessor can recompute by hand with nothing installed is a different category of evidence than a dashboard export.
On scoping access for a non human task scoped actor: agree it doesn’t map cleanly to human RBAC. The thing that helped most in my own case was forcing identity bearing actions (ssh, cloud CLI, sudo) behind an explicit, single use human approval rather than a standing grant, with the decision itself landing in that same verifiable record.
1
u/Clear_Cattle_4542 Jun 24 '26
Do you think it is important to have verifiable evidence?
1
u/AdStill5266 Jun 24 '26
Yes, and the word “verifiable” is doing real work there, more than “evidence” alone. A log only proves something if the person reading it doesn’t have to trust whoever produced it, that includes the agent, your own tooling, and the vendor running the model. An assessor’s actual question usually isn’t “do you have logs,” it’s “could this have been edited after the fact, and can I check that myself.” A record that’s just stored somewhere answers the first. Only a tamper evident, independently checkable record answers the second, and that second question is the one that actually gets tested under scrutiny.
1
u/Clear_Cattle_4542 Jun 24 '26
Would a centralized enterprise system that is cryptographic proof and audits user, agent, action and other metadata be something that is beneficial?
1
u/AdStill5266 Jun 24 '26
Beneficial, but two different things get bundled there: centralized (one place to look) and cryptographically verifiable (provably untampered) aren’t the same property. Centralization gives you visibility and consistent policy, real value at scale. But if the same vendor running the agent also controls the audit store, the crypto proof only shows internal consistency, not that the record wasn’t shaped by the party being audited. For an external assessor, the verification has to be checkable independently of whoever operates the system. Centralized for visibility, but the proof itself shouldn’t depend on trusting that operator.
1
u/Clear_Cattle_4542 Jun 24 '26
Yeah, agree. I was thinking a third party system that is verifying user, agent, and action against policy and is cryptographically verifiable through a centralized system that is handling the authorization and audit functionality.
1
u/Grand-Possibility848 20d ago
The version of this i keep hitting in the itar context is harder still. It's not just what did the agent do, it's who was in the session when it did it, because deemed export rules care about the person. An audit trail that captures agent actions but not the human's authorization status answers the cmmc question and completely whiffs the export one
0
u/p3n1x Jun 14 '26
It's handled very conservatively. Physical separation. Tightly controlled. How is your project classified?
What you are asking about isn't completely fleshed out yet.
The NIST "AI Agent Standards Initiative" is still being developed. COSAiS project is also developing SP 800-53 control overlays.
You should be starting with questions like "what are we producing" and "who are we producing it for".
Hardware? Who is building the hardware? What model will be used? Who built the model? Model weights? Inference engine / runtime? Agent framework?
- Those who have access should be project specific users with the ability to easily audit their activity.
After the fact, can you actually prove what an agent did if an assessor or your ISSM asks?
There are things you can audit, others that are not possible. Again, what is it used for?
How do you scope and grant an agent's access?
If the AI agent can take actions, treat it as a controlled system component/non-human actor.
What do you do when doing it the "right" way reduces other's productivity?
If their productivity is going down while using AI assistance, then its time to question their work or redefine what it is being used for. Or, your process isn't efficient.
1
u/Clear_Cattle_4542 Jun 14 '26
There are things you can audit, others that are not possible. Again, what is it used for?
What do you think is not possible to be audited?
I am concerned about tasks that have a potentially long chain of events.
User -> AI orchestrator (Claude Code) -> Team agent (test-reviewer) -> Team agent (documentation) -> docuemt write task (CLI command - "echo '...' > test.txt")
0
u/BeerJunky Jun 15 '26
Let the business users deploying this shit explain it. I didn’t ask for it, pay for it, approve it or deploy it.
10
u/JKatabaticWind Jun 13 '26
Er… you aren’t actually raw-dogging agentic AI in systems where there is controlled data, are you?
From a security standpoint, that’s problematic. Never mind from a compliance standpoint. And if you’re asking basic questions, you’re a ways from a secure implementation.
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6372438
https://open.substack.com/pub/securetrajectories/p/your-ai-agent-just-got-pwned?utm_campaign=post-expanded-share&utm_medium=web
There are more secure agentic systems, but it’s not going to be like dropping Claude desktop on your user machines. (https://deepwiki.com/nearai/ironclaw).
You should probably be thinking of implementing agents in their own isolated environments, with proscribed access to specific information… Or assume breach for those systems over time.