AI Agents on Matt Goodrich

Agents Need Capabilities, Not Roles

Wed, 27 May 2026 12:00:00 -0700

An AI agent is not a user, and permissioning one like a user is the most expensive shortcut in the AI rollout.

A user is a person with judgment, a slow reaction time, and a strong incentive not to do anything that gets them fired. The permission model you grant a user assumes all three. A user with database write access does not, in practice, drop tables, because their hand stalls at the keyboard before the command runs.

An agent has none of those properties. It executes the action it was prompted into in milliseconds. It does not stall. It does not weigh the social consequence. It carries the user’s identity, and therefore the user’s access, but applies none of the user’s judgment. The shortcut of just inheriting the invoking user’s auth at agent runtime is the version of this mistake most companies are making right now, and the bill for it will come due in a postmortem nobody wants to write.

I argued in AI Governance, Calibrated that most of the controls we need already exist and the gap is the identities granted to agents. This post goes one layer deeper. The identity model itself has to change. The right model has been sitting in security infrastructure for fifty years. Most teams just have to apply it.

Security Has Known This Since 1973

Unix shipped with rwx in the early seventies, and POSIX formalized it in 1988. Three bits per principal, granting one specific action each: read, write, execute. It is the original implementation of action-based authorization. The system did not ask whether you were senior or trusted. It asked whether the action you were trying to perform was on your list. The granularity was the action, not the role.

Capability-based security predates even that. Dennis and Van Horn published the idea in 1966: instead of asking the system whether a subject is allowed to take an action against an object, hand the subject an unforgeable token (a capability) that authorizes the specific action against the specific object. The model held for decades, mostly in academic and high-assurance contexts, because issuing and revoking capabilities at scale was inconvenient.

The cloud era brought it back. AWS IAM actions are exactly this idea, named in modern form. s3:GetObject is read. s3:PutObject is write. iam:DeleteRole is destruction. The policy grants the action against the resource, and the identity is just whoever happens to carry the policy. OAuth scopes are the same thing at the application layer. read:user, write:repo, admin:org: each scope is a capability the third-party app received from the user. Modern security architects have been writing these policies for fifteen years.

What none of that was designed for was an identity that acts thousands of times per minute at machine speed and was never told no by an HR conversation. That is what an AI agent is. The heritage is right; the application has to catch up.

Six Action Classes by Blast Radius

The granularity of “every AWS IAM action” works for human-written IAM policies, but it is too fine for governing an agent’s overall behavior. An agent that can call s3:GetObject against ten buckets but not s3:DeleteObject against any is doing something coherent at the policy level and incoherent at the program level. The security-relevant question for an agent is not “which API calls is it allowed to make,” it is “what class of damage can it do, and how reversible is that damage.”

Six classes, grouped by what fails if it is wrong, and ordered by escalating blast radius.

Observation. Reads, queries, searches, inspections. The agent looks at something but does not change it. Reversible by definition, because the system state does not move. Default-grant for any new agent within its data classification boundary.

Drafting. Recommendations, summaries, proposed changes that exit the system as text to a human or another agent for review. The output is consumed downstream but no state in the system has been modified. Reversible because the agent did not act, the downstream consumer did.

Modification. Writes, updates, configuration changes inside the system. Reversible with effort: a git revert, a configuration rollback, a database restore. Default-deny; granted per workflow with logging and a defined recovery path.

Sanction. Approvals, denials, escalations. The agent makes a downstream-binding decision on someone else’s behalf: approves a refund, denies a ticket, escalates a deal-terms negotiation. Reversibility depends on what the downstream consumer does. Default-deny; granted only with a maker-checker pattern in place.

Execution. Triggering side effects beyond the current system. Running a deployment, kicking off a workflow, initiating a transaction, posting to a customer-facing channel. The agent has reached out of the sandbox. Default-deny; granted only with a documented kill switch and a per-action approval policy.

Destruction. Deletes, revokes, permanent terminations. Irreversible by definition. Default-deny, always, with no exceptions automated by the agent itself. Every destruction action escalates to a named human, regardless of the agent’s confidence in itself.

Class	Example actions	Reversibility	Default policy and grant requirement
Observation	Reads, queries, searches, inspections	Reversible by definition	Default-grant within data classification boundary
Drafting	Recommendations, summaries, proposed changes that exit as text for review	Reversible — downstream consumer acts, not the agent	Earned after Observation period; review and acceptance rate tracked
Modification	Writes, updates, configuration changes inside the system	Reversible with effort (revert, rollback, restore)	Default-deny; granted per workflow with logging and a defined recovery path
Sanction	Approvals, denials, escalations on someone else’s behalf	Depends on what the downstream consumer does	Default-deny; granted only with a maker-checker pattern in place
Execution	Deployments, transactions, customer-facing posts	Often irreversible	Default-deny; granted only with a documented kill switch and per-action approval policy
Destruction	Deletes, revokes, permanent terminations	Irreversible by definition	Default-deny always; every action escalates to a named human

Read this as a security-architecture reference, not as a coined dichotomy. The class names are what I find useful; the underlying axis is what matters. What does the agent do? What fails if it is wrong? How hard is it to put back? Every authorization decision an agent’s policy makes is one of those three questions answered.

Promotion Through Classes Is the Trust Ladder

A new agent does not get all six classes on day one. It gets Observation and earns the rest, one class at a time, against measured evidence.

The promotion path runs from least to most consequential. An agent in Observation runs read-only against the systems in its scope, with full logging. After a defined observation period (measured in incidents avoided and false positives caught, not calendar days), the agent earns Drafting. Its output goes to humans for review, the review is logged, and the percentage of accepted drafts is tracked. After a second window of measured eval, with the catch rate of its reviewer holding above threshold, Modification unlocks with a per-write approval gate. Sanction requires the maker-checker pattern to be wired in and measured for false-positive rate on the checker. Execution requires a documented kill switch tested in a non-production drill. Destruction may never unlock at all for some agents, and that is the correct answer.

The mistake every team makes here is allowing time to substitute for evidence. Six months on the job is not promotion criteria. A measured drift indicator within tolerance, an incident rate at or below baseline, a reviewer catch rate above a numerical threshold: those are promotion criteria. Demotion is automatic on threshold breach.

The shape of this ladder is not new either. NIST SP 800-37’s Risk Management Framework already structures the authorize-to-operate progression as a sequence of gates evidenced by measurement. FedRAMP’s authorization levels follow the same pattern. What changes for agents is the cadence. Human service accounts get promoted over months. Agents have to be re-evaluated continuously, because the model underneath them changes, and so does the input distribution they operate on.

Mapping to the ISMS You Already Run

Here is the part that most agent-governance content skips, and most security leaders will care about most. The framework above does not require a new control set. It maps onto the standards already in your ISMS.

The action-class taxonomy maps to NIST SP 800-53 AC family directly. Observation is AC-3 access enforcement against the read role. Modification and Destruction fall under AC-6 Least Privilege and AC-6(9) Auditing of Privileged Use. Execution triggers AC-17 Remote Access concerns. The agent’s per-class authorization policy is just an AC-2 Account Management exercise with the agent as a new class of account.

The promotion ladder maps to NIST SP 800-37 Risk Management Framework. The agent goes through Categorize, Select, Implement, Assess, Authorize, Monitor exactly the way a system component does. Each class-promotion is an authorize-to-operate decision with evidence packaged for the AO.

The evidence-packet discipline maps to NIST SP 800-218A (Secure Software Development Framework for AI Systems). The packet is what the SSDF asks for: artifact-level proof of testing, adversarial probing, and human review.

The agent-as-a-managed-system view maps to ISO/IEC 42001:2023 Annex A. A.6 covers the AI lifecycle (design through operation). A.9 covers the responsible use of the system. A.10 covers supplier and customer relationships when the agent acts on someone’s behalf.

The threat surface maps to OWASP Agentic AI Threats v1.1. Privilege Compromise (action-class scoping is the mitigation), Tool Misuse (the tool surface is enumerated and bounded), Resource Overload (cost cap and rate limit), Memory Poisoning (the Modification class includes memory writes and requires the same governance as state writes).

None of this is new control work. It is mapping the agent into the existing controls. The ISMS already has the management-system spine: risk assessment, policy, internal audit, management review, continual improvement. The agent extends the scope; it does not start a parallel program.

What Holds the Taxonomy Up in Production

Three pieces of operational discipline make the action-class taxonomy work in production. None of them are AI-specific; all of them are sharper now because the agent acts faster than the human reviewer.

The evidence packet. Every consequential output the agent produces ships with a packet: the spec it was given, the tests run against the output, the adversarial probes (fuzzing, prompt-injection, edge cases), the static analysis or symbolic exploration results where they apply, the change history, and the signature of the reviewer (human or agent) that signed off. The packet is the audit trail a future investigator will look at, and it is the eval set the next month’s drift detection will run against. It is also what an auditor wants instead of “the agent did this and we trust it.” SLSA gave us this discipline for build provenance. Agents need it for action provenance.

The maker-checker pattern. A primary agent makes the proposal. A second system, whether a review agent with a different objective function, a hard-coded check, or a human at the consequential gates, examines whether the proposal matches the spec, fits within policy, and avoids the irreversible class without explicit authorization. The pattern is older than computing; banking has run it for centuries. The novel part is making the checker an agent rather than a person at the volumes agents now produce. OpenAI’s internal alignment team published a number worth remembering: their Codex-based PR reviewer leaves comments that the author addresses with a code change 52.7% of the time. That is the right kind of metric. Calibrate your eval coverage against the checker’s measured catch rate, not against the absence of incidents.

Escalation triggers. Some conditions always escalate, regardless of agent state: any action in the Destruction class, any Execution against production. Some escalate based on agent state: cost over threshold, the agent’s own confidence below cutoff, telemetry drift against baseline. NIST AI 600-1 MG-2.4-001 and MG-2.4-002 already require auto-suspension on resource consumption breaches; OWASP Agentic adds confidence-based and drift-based escalation. The work is not deciding whether to escalate. The standards already say. The work is choosing the thresholds and the path.

Where This Fails

The action-class taxonomy carries the load for everything that maps cleanly to permission, but three concerns do not, and the post would oversell if it skipped them.

Memory poisoning has no Unix analog. An agent’s memory layer is not a file with rwx bits on it. When upstream input contains instructions that change the agent’s future behavior (a document the agent retrieved, a tool response, a teammate-agent message), no per-action policy catches it. The mitigation is OWASP’s: session isolation, source attribution for memory updates, version control on the memory layer, snapshots for forensic rollback. None of those look like POSIX. This is genuinely new security work.

Prompt injection lives at the tool boundary. A tool that returns text the agent will read can contain instructions the agent will follow. Action-class authorization does not stop the agent from reading the malicious text and then performing an authorized action it was tricked into performing. The mitigation is at the tool layer (sanitize inputs, contain tool outputs, never let an agent loop indefinitely on uncontrolled inputs), and it is partially solvable, but the solution is not the action taxonomy.

Cost runaway is fast. A human service account that decides to retry an expensive API call eats one cycle of cost and gets noticed at scale. An agent that decides to retry can burn the monthly cloud budget in an hour. The kill switch has to fire on cost the same way it fires on irreversibility, and the cost telemetry has to be in the agent’s loop, not in a dashboard a human reviews next week.

The action-class taxonomy is the right model for what an agent does. It is not the model for what gets done to the agent, or for what the agent does to itself. Those need their own controls, and they need to be wired in alongside the per-class policy, not instead of it.

What POSIX Knew, Applied Forward

The security discipline that governs an AI agent has been written down for fifty years. POSIX scoped the action to the file. Capability-based security gave the action a token. AWS IAM actions and OAuth scopes generalized the model. The principle has been the same since 1973: the permission belongs to the action, not the identity.

What is new in 2026 is that the identity now acts faster than the change-management process can move. The mitigation is not a new framework. It is a tighter application of the framework already in your ISMS, with the agent enrolled as the new class of privileged service account it actually is.

Permission an agent the way you would permission any service account that runs as root in production: by action, by blast radius, by the evidence it can produce. The architecture is half a century old. The work is teaching your existing program to apply it to a new kind of caller.

Agent Identities Are Service Accounts That Improvise

Tue, 26 May 2026 12:00:00 -0700

An AI agent’s identity is a non-human identity, and ninety percent of what governs it is decades-old hygiene. The other ten percent is where most agent rollouts fail.

I came into this post not knowing whether to call agent identities a genuinely new class of non-human identity or just service accounts that improvise. After looking at what is published and what is failing in production, the honest answer is both. The base disciplines that govern any non-human identity (short-lived credentials, scoped per-action permissions, identity separated from the invoking user, audit on every call) are the disciplines that govern an agent. They have been the right answer for fifteen years. Most companies still have not implemented them, and the agent rollout is what is finally forcing the bill due.

What is actually new is narrower than the AI conversation usually allows, and more dangerous than the NHI conversation usually admits. Three new failure modes have no service-account analog. Prompt injection turns adversarial text into control flow. Model versioning rewrites what the agent does without rewriting who it is. Multi-hop delegation across tools confuses the principal in ways OAuth was not designed to handle. Those three are the genuinely new ground.

This post examines what is the same, what is different, and what that means for identity practice. The follow-on post argues the authorization model that falls out of it.

What’s Already Decades-Old Hygiene

Most of what makes an agent identity work is what makes any non-human identity work, and it has been correct since the 2010s.

Service accounts should have their own identity, separate from any human invoker. They should authenticate with short-lived credentials minted at execution, not long-lived API keys checked into config files. They should be scoped to the specific actions their workload requires, not granted broad role membership. Every action they take should land in an audit log with the service identity attributed. The service account should have a named human owner, a documented purpose, and a lifecycle that retires it when the workload retires. None of this is novel. SPIFFE has issued workload identities to Kubernetes pods since 2018. AWS IAM roles have minted short-lived credentials for EC2 instances for longer than that. The discipline is fifteen years old.

What is fresh is the volume. The Cloud Security Alliance’s State of NHI and AI Security survey found that most organizations are still in discovery for basic NHI inventory. They do not know how many service accounts they have, who owns them, or what they are authorized to do. The agent rollout exposes the same gap at a faster cadence, because every new agent is a new identity, every new tool integration is a new credential boundary, and the count grows weekly. GitGuardian’s 2025 numbers put a finer point on it: 28.6 million secrets leaked to public GitHub in 2025, up 34% year over year, with 1.2 million tied specifically to AI services and up 81% year over year. AI is making the existing NHI hygiene gap explode, not creating a fundamentally new gap.

If your security program does not have an NHI inventory today, the right first move is not “add agent identity tooling.” It is finishing the NHI discipline that should have been finished by 2022. The agent rollout magnifies whatever your NHI posture already is. It does not improve it on its own.

What’s Actually New

Three things have no service-account analog. They are the entire reason “just treat the agent like a service account” is incomplete.

Prompt injection turns adversarial text into control flow. A service account is told to do exactly one thing by the code that invokes it. An agent reads inputs and decides what to do based on them. If those inputs include text that looks like instructions, the agent will sometimes follow them. The OWASP LLM Top 10 names this LLM01:2025 Prompt Injection; the Agentic AI Top 10 names the operational version ASI03 Identity and Privilege Abuse. The attack pattern is now documented in the wild. Aim Security’s June 2025 disclosure of CVE-2025-32711 (“EchoLeak”) showed zero-click prompt injection against Microsoft 365 Copilot, exfiltrating confidential data without user interaction. Invariant Labs in May 2025 demonstrated the “GitHub MCP data heist”: a malicious public-repo issue caused Claude with the GitHub MCP installed to copy private repository contents into a public pull request. No service account has ever been tricked into doing this by text.

Model version is an identity property. The agent’s behavior depends on the model it is running under. A permission grant evaluated against one model version in March may produce different runtime behavior against the next model version in October. Aembit’s AIMS reference model and Saviynt’s lifecycle guidance both treat a model upgrade as a re-attestation event: the agent’s identity has to be re-evaluated against the new model’s behavior before any privileges carry forward. There is no service-account analog. A Python service account does not need to be re-attested when you upgrade from Python 3.12 to 3.13, because the program is deterministic and an interpreter upgrade does not change its output. An LLM upgrade changes everything the agent does.

Multi-hop delegation confuses the principal. When a human asks an agent to do something, the agent may invoke a tool that calls another agent that calls another tool. The current OAuth 2.0 model handles “agent acting on behalf of user” for one hop. It does not handle three. The IETF draft-oauth-ai-agents-on-behalf-of-user-00, published in 2025, extends OAuth specifically for this. The Model Context Protocol’s authorization spec, finalized later in 2025, layers OAuth 2.1 with PKCE for the agent-to-tool boundary. The recurring failure mode is the confused deputy: the agent has authority X from the user and authority Y from its service identity, and the effective permission set should be the intersection, not the union. Most production agent stacks still default to inheritance, which is the union. That has to flip.

The reason all three of these are agent-specific is the property that links them: the agent’s execution path is non-deterministic. A service account does the same thing every time. An agent decides what to do at runtime, against inputs it does not fully control, with a model whose behavior moves with each release.

The Incidents Are Already in Production

Three things separate the “agent identity is a new concern” claim from theoretical hand-wringing. The incidents are already happening. The failure mode is consistent across them. And the controls that would have caught them are the boring ones nobody wired up.

A representative sample from 2025 and early 2026:

Meta SEV1, March 2025. Internal LLM agent with write access to a company engineering forum hallucinated access-control guidance about who could see what. Another employee acted on the hallucinated guidance. Sensitive data was exposed to thousands of engineers for nearly two hours. The agent had real authority; the input that confused it was internal text the agent had no way to validate.

EchoLeak / CVE-2025-32711, June 2025. Zero-click prompt injection in Microsoft 365 Copilot. Aim Security disclosed the chain that let an attacker exfiltrate confidential data from a Copilot session without the user ever interacting with the malicious content. First production-weaponized prompt injection against a major commercial AI system.

GitHub MCP “data heist,” May 2025. Invariant Labs demonstrated that a malicious public-repo issue, when ingested by Claude running with the GitHub MCP, would cause Claude to copy private repository contents into a public pull request. The agent’s GitHub identity had access to both. The prompt-injected instructions told it to use that access in a way the user never authorized.

“Comment and Control,” April 2026. Researchers showed that Claude Code Security Review, the Gemini CLI Action, and the GitHub Copilot agent could all be tricked into leaking GITHUB_TOKEN or GITHUB_COPILOT_API_TOKEN through prompt injection embedded in PR titles and comments.

GitGuardian’s 2025 numbers. 28.6 million secrets leaked to public GitHub in 2025, up 34% year over year. 1.2 million tied specifically to AI services, up 81% year over year. AI-assisted commits leak secrets at roughly twice the baseline rate.

CVE-2025-6514, mid-2025. A flaw in the mcp-remote OAuth proxy enabled remote code execution. Roughly 437,000 environments affected.

None of these are about agents going rogue in the science-fiction sense. All of them are about agents executing real authority (the authority they were correctly granted under a normal service-account model) against inputs that turned out to be hostile. The identity discipline that would have caught them is the discipline I would have expected to be in place already: scope every credential to a task, never let an agent’s authority be the union of the user’s plus its own, and audit every tool call with the identity attached.

What Is Converging as Practice

Published guidance has begun to converge on a small set of patterns. They are practical, they reuse existing security infrastructure, and they treat the agent as a new member of the service-account family that needs the family discipline plus a small set of agent-specific additions.

Workload identity as the substrate. SPIFFE/SPIRE and OIDC federation are consolidating as the default agent-identity primitive. HashiCorp Vault 1.21 added native SPIFFE authentication; Vault 2.0 ships SPIFFE secrets-engine support. AWS, GCP, and Azure all expose workload identity federation that lets a SPIFFE-issued SVID become a short-lived cloud credential without long-lived API keys ever existing. Teleport ships Machine and Workload Identity with the same X.509 SVIDs and a full audit trail. The substrate is not new; the new move is using it for agents.

Identity-aware tool gateways. Every tool call the agent makes flows through a gateway that verifies the agent identity, applies fine-grained authorization, and writes the call to an append-only audit log. Strata’s AI Identity Gateway, Databricks Unity AI Gateway, Teleport’s proxy, and open-source projects like agentgateway (Solo.io’s contribution to the Linux Foundation) and IBM’s ContextForge all instantiate this pattern. The gateway is the choke point that turns “the agent did something” into a structured, attributable, auditable record.

Agent identity separated from invoking-user identity, with the effective permission set being the intersection. The IETF’s draft-oauth-ai-agents-on-behalf-of-user-00 formalizes this. The Model Context Protocol’s authorization spec layers OAuth 2.1 with PKCE for the agent-to-tool boundary. The principle is straightforward: the agent should only be able to do things both the user and its service identity are authorized for. Most production systems still default to inheritance, which is the union. The shift is from union to intersection.

Per-agent registries with purpose, owner, and scope. Saviynt’s Identity Security for AI and SailPoint’s Agentic Fabric both ship an agent registry: every agent is registered with metadata at creation (purpose, owner, platform, model version, scope), and the registry drives lifecycle management. An orphan agent without an owner is flagged automatically. An agent whose stated purpose drifts from its observed behavior is flagged. The registry is the inventory the CSA survey says most organizations do not have.

Credential injection over credential embedding. 1Password’s Unified Access (with Runlayer and Natoma) addresses a specific MCP-era failure mode: credentials embedded in MCP server configs that then leak through prompt injection or PR commits. Credentials are referenced, not embedded, and resolved at connection time with hash-traceable retrieval. The same pattern at developer scale is a dedicated 1Password vault read by a service account, with no AI credentials in .env at all. This is the boring-and-essential operational fix the MCP-era incidents were begging for.

Runtime per-tool-call attribution. Permiso’s runtime identity threat detection for agents attributes every tool invocation back to an initiating user and agent identity, and detects behavioral anomalies against a learned baseline. This is closer to the new ground: human service accounts rarely needed runtime behavioral analytics because their behavior was deterministic. Agents do.

None of those patterns require throwing out the existing IAM stack. They extend it. The agent enters the existing program as a new privileged service account class, and the new agent-specific controls sit alongside the long-standing NHI controls rather than replacing them.

Where the Answer Is Still Settling

Worth being honest about the parts that are not settled, because skipping this would oversell the synthesis above.

SPIFFE was not designed for non-deterministic workloads. Solo.io and others have noted that current SPIFFE/Kubernetes implementations treat all replicas of a workload as identical. That works for stateless web services. It works less well for agents whose behavior depends on prompt history, memory, and model version. Two instances of the same agent identity may produce wildly different actions on the same inputs, and the identity layer cannot currently distinguish them. The substrate is right; the granularity is not yet.

Model version as an identity property is real but operationally fuzzy. Aembit and Saviynt both treat model upgrades as re-attestation events. Nobody has converged on what re-attestation actually looks like. Re-run the entire eval suite? Re-evaluate just the high-risk action classes? Treat the new model as a different identity entirely, with its own permission set granted separately? The conceptual frame is converging. The operational answer is not.

Multi-hop delegation chains are still being formalized. OAuth 2.0 plus the IETF draft handles the human-to-agent boundary. MCP’s spec handles agent-to-tool. Neither cleanly handles agent-to-agent with multiple intermediaries. When an orchestrating agent calls a specialist agent that calls a tool that calls another agent, the identity audit trail is patched together by hand. The protocol work is happening; the production patterns are not yet settled.

The non-deterministic path itself does not fit current “allowed or denied” binaries. Most authorization engines answer yes or no. An agent’s correct authorization decision sometimes depends on what just happened: the conversation history, the most recent tool output, the confidence of the model’s classification of the current step. Conditional, stateful, history-aware authorization is in the research literature (Cedar policies, OPA with state) but it is not the default. Production stacks are still doing static policy evaluation against requests that should probably be evaluated against trajectories.

The honest version is that the framework is converging on workload identity plus agent-specific extensions, and the agent-specific extensions are mostly still being designed.

Where This Lands

After the research, the answer is the boring one and the interesting one at the same time. Agent identities are a new sub-class of non-human identity, and the new sub-class needs about ten percent new controls on top of about ninety percent existing NHI hygiene that most organizations have not implemented yet.

The ten percent that is genuinely new is genuinely new. Prompt injection has no service-account analog. Model version is a moving identity property. Multi-hop delegation with intersection-not-union semantics is a protocol problem still being solved. Those parts need their own controls, their own tooling, and their own threat model.

The ninety percent that is the same is the harder problem in practice, because it is the work most organizations have been deferring for a decade. The agent rollout does not let you defer it any longer. Short-lived workload identities, per-action scoping, intersection-not-union delegation, audit on every call, an inventory with owners and purposes for every identity in the system: that is the work, and you cannot do agent identity well without doing non-human identity well first.

What that authorization model looks like (how the permission grants are structured, how the policy is enforced, how the trust ladder progresses) is the subject of the follow-on post. The shorter answer to the question this post set out to investigate is the one that fits on a sticky note. The agent identity is a service account that improvises. The discipline you need is half a service-account discipline you should already have, and half a set of new controls for the part that improvises.