Chapter 01 ended on a simple fact from IBM's own documentation: Bob reaches your system through the user profile of its Code for IBM i connection, and anything that profile can do, Bob can do.1 Chapter 02 showed how much useful work that connection opens up. This chapter is about setting it up well.
The good news for an IBM i shop is that most of this is work you already know how to do. Governing Bob is mostly governing a user profile, and few platforms have spent as long getting that right.
The identityA profile built for the work.
IBM's guidance is direct: give the connection the least privilege necessary, and make sure anything Bob creates lands somewhere secure.1 In practice that means five decisions.
A separate, narrower profile for Bob sessions.
Give each developer a second profile for Bob work, named so it traces back to them. Their everyday profile can stay as it is. Every action Bob takes is then attributable to a named person, and scoped to the work rather than to everything that person is trusted with.
No broad special authorities, including through groups.
Leave out *ALLOBJ, *SECADM and *AUDIT. Check the group and supplemental group profiles too, since their authority comes along with the user's.
Right-size it from evidence.
Authority collection, available since 7.3, records the authorities a profile actually uses. Run it while a developer works with Bob for a normal week, then grant what was used instead of guessing.6 Results are in the QSYS2.AUTHORITY_COLLECTION view.
Keep its workspace private.
Code for IBM i uses a shared temporary library, ILEDITOR, by default. IBM recommends each developer use their own. The same goes for the temporary IFS directory, and the RPGUNIT library ships with public *CHANGE; read access is enough for developers.1
Secure the way in.
The connection runs over SSH. Use keys, turn on multi-factor authentication where it's supported (IBM recommends it), and limit which profiles may connect.1
The reachWhat the profile can really touch.
A narrow profile can still reach further than it looks, because of adopted authority. When a program is created to adopt its owner's authority, anyone running it temporarily gains that owner's authority on top of their own, for as long as the program is in the call stack.5 It's how many IBM i applications have controlled access for decades, and it works exactly as designed when Bob calls a program, too.
So the real question isn't only "what can Bob's profile do?" but "what can it do through the programs it's able to call?" Three habits answer it:
- Know which programs adopt.
PRTADPOBJreports programs that adopt a given owner's authority, with an option to show only what changed since the last run.DSPPGMADPgives the same list on screen.5 Start with programs owned by your most powerful profiles. - Follow IBM's guidance on owners. Don't use IBM-supplied profiles as program owners, and set owning profiles to limited capabilities.5
- Record when adopted authority is used. Adding
*PGMADPto your audit level writes an entry to the audit journal each time a program adopts, so the reach is visible after the fact, too.
The guardrails in BobSettings that decide when it asks.
Bob has its own controls, and the Premium Package for i adds two specific to the platform.2 They don't replace the profile. They shape the conversation inside it.
Keep approvals on for edits and commands.
IBM rates auto-approval of file edits and of commands as high risk and recommends limiting both to controlled environments.3 IBM's Bob team offers a simple rule of thumb: reads can be auto-approved; edits, commands and external tool calls get reviewed.4
Tune the SQL statements that always need a yes.
Statement types on the denied list need explicit approval even when a task has auto-approval. The default list includes UPDATE, DROP, GRANT, REVOKE, MERGE, TRUNCATE and CALL, and IBM invites teams to adjust it to their risk tolerance.2 For connections near production data, many shops will want INSERT, DELETE, CREATE and ALTER on it as well.
Leave qualified CL commands on.
On by default, this setting has Bob library-qualify every CL command it runs.2 The command that runs is exactly the one named, whatever the library list happens to be.
Share one set of rules across the team.
Create a read-only reviewer mode for exploration, and commit the project's .bob/ folder so everyone works with the same modes and rules.4 Use .bobignore to keep keys and credentials out of Bob's view. IBM notes it isn't a system sandbox,3 which is why the profile underneath matters.
The recordBeing able to answer "what happened?"
Governance isn't only what you prevent. It's also what you can show afterward, to an auditor, a manager or yourself.
Audit the Bob profiles by name.
With auditing active on the system, CHGUSRAUD can add command-level auditing (*CMD) for just the Bob profiles, so every command they run lands in QAUDJRN without turning it on for everyone.
Recognize Bob's SQL.
Bob sets the CLIENT_APPLNAME special register on the SQL jobs it uses, to a value naming the Bob extension and its versions.1 Your SQL monitoring can tell Bob's work from everyone else's.
Make database changes reversible.
Journal the files Bob may touch, under commitment control, so a change can be traced and backed out to a known point. Bob 2.0's own rollbacks cover files in the workspace;7 the journal covers the database.
Bob decides when to ask. The box decides what's possible.
That's the pattern across all three chapters so far. Bob brings capability; IBM i brings a boundary that was built long before agents and holds just as well for them. Set up both, and the conversation in your shop moves from "should we let it in?" to "what should it work on next?"
What to do MondayFour moves to a governed first rollout.
Create the Bob profiles.
One per developer, traceable to them, no broad special authorities, their own temporary library. Then start an authority collection on each.
Map the reach.
Run PRTADPOBJ for your most powerful owning profiles and add *PGMADP to your audit level.
Set the team defaults in Bob.
Approvals on for edits and commands, your denied SQL list, qualified CL on, a read-only reviewer mode, all committed in .bob/.
Prove the record works.
Turn on command auditing for the Bob profiles, have one developer run a short task, and query QAUDJRN for it. If you can tell the story of that session from the journal, you're ready to widen the rollout.
See where your platform already stands on identity, reversibility and audit.
Take the IBM i readiness read